Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Karthikeyan Bhargavan]

> I'm aware of that (and related) work, but this is about finding
> multicollisions in MD5 || SHA1.

To be clear, there is no published collision on MD5 || SHA1 right now.

In our paper, we only say that *if SHA-1 collisions were to appear* with 
complexity 2^x, 
then MD5||SHA1 collisions would cost 2^(6+x). Hence, if the current estimate of 
2^61 for SHA1
were true, then the cost of MD5||SHA1 is 2^67. 

It is up to protocol designers and implementers to decide whether this is an 
acceptable security margin.
If we decide to wait for a “real” SHA-1 collision to appear, then we must be 
prepared for “real” attacks to appear soon after.

Best,
Karthik


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

Re: [TLS] Early code point assignment for draft-ietf-tls-curve25519-01

[Simon Josefsson]

Joseph Salowey  writes:

> Please respond if you have concern about early code point assignment for
> the curves listed in draft-ietf-tls-curve25519-01
> .

The above draft, and rfc4492bis and tls13-11, has known
issues/inconsistencies related to X25519/X448 that have been discussed
on the list.  When it was decided (offlist..) to move the content of
draft-ietf-tls-curve25519 to other documents, I stopped working on it.

What would the semantics of these code points related to the known
issues be (e.g., code point validation or not)?  Do the code points
refer to what the draft above says, or what people appear to prefer
(don't reject, but ignore set bit) and have been implementing?

I can update the document to fix the known issues.  The content has been
copied to other documents that I have no editor influence of, so
modifying draft-ietf-tls-curve25519 may make the situation even more
confusing.  Please advice if you want anything more to happen with the
document above.

/Simon


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Stephen Farrell]

A few notes on this:

- Calling for the IETF to do something isn't how it works. People
who want thing X to be done need to write the draft and then see
if it gets support. I suspect an md5-die-die-die draft would get
quite a bit of support but...

- The points Victor made about long-term stored data are valid.
In various cases it simply wouldn't be a good plan to re-encrypt
or re-sign old data. Yes, that stored data may not be as secure
as it once was, but it may be impractical to re-encrypt it all.
The openpgp wg [1] are dealing with this particular issue as they
work to do updates, so feel free to get involved in that debate
there if it's of interest.

- If your envisaged scope is for all IETF protocols, then I'm sad
to say there may be "fun" ahead wrt TCP-MD5 [2] which some routing
folks just won't let die it seems, even though we formally obsoleted
that [3] 5 years ago. (And yes, that really is sad.)

- Lastly, and again if your envisaged scope is to deprecate MD5 for
all IETF protocols then that might better fit the charter of the new
curdle wg. [4] And your draft might be an update to RFC6151 [5] I
guess, depending on how you wrote it.

So by all means, write the draft and post a link to the curdle
list (maybe cc'ing this).

Cheers,
S.

[1] https://tools.ietf.org/wg/openpgp/
[2] https://tools.ietf.org/html/rfc2385
[3] https://tools.ietf.org/html/rfc5925
[4] https://tools.ietf.org/wg/curdle
[5] https://tools.ietf.org/html/rfc6151


On 12/01/16 03:42, Dave Garrett wrote:
> On Monday, January 11, 2016 06:13:37 pm Tony Arcieri wrote:
>> My understanding is TLS 1.2 specifically was amended to allow MD5 
>> signatures even though this was not the case in previous TLS
>> versions, or at least that was the claim of the miTLS presenters on
>> SLOTH at RealWorldCrypto 2016.
>> 
>> If this is the case, this seems like a big regression in TLS 1.2.
> 
> I'd like to propose killing the low hanging fruit first, and then
> continue to build on top of that.
> 
> No sane person disputes that MD5 needs to be eradicated ASAP. We're
> keeping MD5||SHA1 in old TLS for compatibility and we are well aware
> that needs to go eventually too. Thus, I suggest we publish an MD5
> diediedie standards track RFC to prohibit ALL standalone MD5 use in
> ALL IETF protocols/standards. Constructions using MD5 with something
> else (namely MD5||SHA1) would also be explicitly recommended against
> in existing specifications, and explicitly prohibited in all new
> drafts (even if unlikely).
> 
> Also, when I say "prohibited" here, I mean _completely_. No MD5
> function should remain in the relevant codebase; if MD5||SHA1 support
> is continued, there should be one function that does only that
> without any way to get a plain MD5 hash. (and no "it's fine for this"
> junk; non-broken hashes are also fine for that, and if you're wrong,
> it's safer) There are too many implementation bugs in this realm to
> not state this explicitly [0].
> 
> Note that continued support of trust anchors with MD5 hashes is not
> dependent on this, as we've already agreed they don't need to be
> validated. (they need to be phased out, but with less urgency) If
> used within this specific context, nothing even needs the ability to
> understand MD5 hashes at all in order to handle these; the
> certificate as a whole is trusted or not.
> 
> 
> Dave
> 
> 
> PS To whomever came up with the "diediedie" term, thank you. ;)
> 
> 
> [0] Note the 3 disabled-but-accepted bugs listed here: 
> https://www.mitls.org/pages/attacks/SLOTH#disclosure
> 
> ___ 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] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Martin Rex]

Tony Arcieri wrote:
[ Charset UTF-8 unsupported, converting... ]
> Peter Gutmann  wrote:
> 
>> The vulnerabilities shown in the SLOTH paper were based on the fact that
>> implementations still allow MD5 for authentication/integrity protection,
>> even if (for example) it's explicitly disabled in the config.
>> So the problem wasn't a fault in the protocol, it's buggy implementations
>> (as it was for ones that allowed 512-bit keys, non-prime primes,
>>  and so on).  Throwing out TLS 1.1 based on this seems rather premature.

Actually no, the TLSv1.2 made a few terribly braindead design choices
  - newly introduce raw md5RSA digital signatures into TLSv1.2 in 2008
where all prior TLS protocol versions, including SSLv3 had been using
the concatenation SHA-1||MD5
  - making the sha1RSA rather than sha256RSA digital signature algorithm
the default and mandatory-to-implement algorithm for use with TLSv1.2(!!)
although it was well-known weaker than the algorithm (SHA-1||MD5)
in all earlier TLS protocol versions, including SSLv3,
and in spite of SHA-1 already being officially scheduled for end-of-life
2 years later (NIST, SP800-57 pt.1 rev2)
This is ridiculous considering that SHA-256 is mandatory-to-use
in the TLSv1.2 PRF.
  - failing to adjust the truncation of the HMAC output in the
TLSv1.2 Finished handshake message to be at least half the size of
the underlying hash function (SHA-256), see RFC 2104 Section 5:

https://tools.ietf.org/html/rfc2104#section-5



> 
> My understanding is TLS 1.2 specifically was amended to allow MD5
> signatures even though this was not the case in previous TLS versions, or
> at least that was the claim of the miTLS presenters on SLOTH at
> RealWorldCrypto 2016.
> 
> If this is the case, this seems like a big regression in TLS 1.2.

And a fairly well-known & discussed regression, e.g.

http://www.ietf.org/mail-archive/web/tls/current/msg10664.html

that was subsequently removed in OpenSSL 1.0.1f in January 2014,
i.e. 2 years before the SLOTH paper.


I'm also wondering whether it might be misleading to lump the
(in)significance of the currently known collisions for HMAC-SHA1
and HMAC-MD5 together with the (in)significance for 
(general, low-frequent) digital signatures and together with
PKCS#10 & Certificate-issuance design flaw that enables a
mere collision attack to achieve what would normally require
a successful 2nd preimage attack.

Compare the Security Considerations of rfc2104 for the (in)significance
of current collision attacks for HMAC.

https://tools.ietf.org/html/rfc2104#section-6


-Martin

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

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Hubert Kario]

On Tuesday 12 January 2016 05:32:08 Viktor Dukhovni wrote:
> On Mon, Jan 11, 2016 at 10:42:45PM -0500, Dave Garrett wrote:
> > No sane person disputes that MD5 needs to be eradicated ASAP. We're
> > keeping MD5||SHA1 in old TLS for compatibility and we are well
> > aware that needs to go eventually too. Thus, I suggest we publish
> > an MD5 diediedie standards track RFC to prohibit ALL standalone MD5
> > use in ALL IETF
> > protocols/standards.
> 
> With some exceptions, for example:
> 
> * As you note in your last comment, X.509 self-signatures via
> MD5 may continue to be ignored, once MD5 is "banned" in the same
> way that they should have been ignored before it was "banned".
> 
> * S/MIME parsers may continue to parse old S/MIME messages with
>   MD/5 signatures.  More generally, Encrypted data at rest may
>   need support for MD5 for the lifetime of the data (until
>   re-encrypted, ...).

in case of digital signatures, that means "lifetime of the data", you 
can't expect them being possible to re-sign

so it must not completely forbid use of MD-5 in implementations of stuff 
like PAdES-A. Though it should strongly recommend allowing its use in 
only *very* specific circumstances.

-- 
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] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Karthikeyan Bhargavan]

> I'm also wondering whether it might be misleading to lump the
> (in)significance of the currently known collisions for HMAC-SHA1
> and HMAC-MD5 together with the (in)significance for 
> (general, low-frequent) digital signatures and together with
> PKCS#10 & Certificate-issuance design flaw that enables a
> mere collision attack to achieve what would normally require
> a successful 2nd preimage attack.

I couldn’t really parse this sentence very well, but here are some 
clarification.

As far as we know, HMAC-MD5 and HMAC-SHA1 are still sufficiently strong MAC 
functions,
and their use in the TLS Record is not vulnerable to currently known attacks.

TLS also uses HMAC in other situations though, and those may well be vulnerable 
to collisions.
In particular, the Finished message in TLS 1.1 is not a strong MAC because it 
first hashes
the transcript before applying the HMAC. Similarly, the use of truncated HMACs 
in Finished
breaks tls-unique and weakens the renegotiation indication countermeasure.

Generally, HMAC uses as a MAC is ok, but when used as a hash function is as 
vulnerable
to collisions as the underlying hash function.

Coming back to digital signatures, all uses of weak hash functions are 
essentially broken. 
The attacks on certificates were well known, and SLOTH shows that other uses
of digital signatures in many mainstream protocols also require collision 
resistance.

Best,
Karthik


> 
> Compare the Security Considerations of rfc2104 for the (in)significance
> of current collision attacks for HMAC.
> 
> https://tools.ietf.org/html/rfc2104#section-6
> 
> 
> -Martin
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

[TLS] Fixing TLS

[Peter Gutmann]

Martin's comment reminded me of the following that I've been meaning to
post...

In a recent discussion among some crypto folks, the topic of what TLS 1.3
could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
centered around the fact that we already have lots of analysis done for TLS
1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
problems while being as compatible as possible with existing infrastructure.
So what this would do is take existing security analysis applied to TLS,
namely:

Bhargavan et al, "Proving the TLS handshake secure (as is)".

Brzuska et al, "Less is more: relaxed yet compatible security notions for key
exchange".

Dowling et al, "Modelling ciphersuite and version negotiation in the TLS
protocol".

Firing, "Analysis of the Transport Layer Security protocol".

Gajek et al, "Universally Composable Security Analysis of TLS".

Giesen et al, "On the security of TLS renegotiation".

Jager et al, "On the security of TLS-DHE in the standard model".

Krawczyk et al, "On the security of the TLS protocol".

(and probably several more) and use them to simplify TLS 1.2 to create an
improved TLS that leverages about 15 years of analysis, rather than creating
what's almost a new protocol based on bleeding-edge/experimental ideas,
mechanisms, and algorithms.

The discussion started out somewhat informally so by the time it got really
interesting it was too late to take notes, but I thought I'd try and recreate
the design points...

- Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
  HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
  SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
  instead of GCM as the AEAD if it were freely available).

- For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as
  well).

- Get rid of the IPsec cargo-cult MAC truncation.

- For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
  allow verification (for those who don't have a copy of X9.42, it requires
  the same verification steps as FIPS 186 does).  Also, mix the hash of the
  DHE values into the computed premaster secret to protect against use of
  manipulated curves.

- RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
  done as encode-then-compare, which fixes all known padding-manipulation
  issues).

- No compression or rehandshake.

- Replace the PRF with HKDF?  (No pressing need for this, but it would be part
  of the general cleanup).

Longer discussion points:

- The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
  between server-specified ephemeral parameters and IETF-blessed fixed ones.
  Arguments can be made either way, we had de facto IETF-blessed fixed DHE
  params in the form of the RFC 2409 ones, but that wasn't such a good idea.
  OTOH with ephemeral DHE params many implementations didn't check them, but
  then the spec never required any checking (or much of anything at all in
  regard to DHE use, which no doubt contributed to some of the dubious
  practices that have been found in the wild).  The situation wasn't helped by
  the use of the PKCS #3 representation, which the requirement to use the
  X9.42 form alongside the accompanying checks attempts to address.
  
- Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
  ones are obviously better (for various values of better, see endless debates
  elsewhere), but some people will insist on only using something that's come
  from NIST (I'll reserve my opinion on that one, and wouldn't dream of
  stooping to phrases like "cargo cult protocol design"...).

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

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Hubert Kario]

On Tuesday 12 January 2016 14:24:31 Martin Rex wrote:
> Tony Arcieri wrote:
> [ Charset UTF-8 unsupported, converting... ]
> 
> > Peter Gutmann  wrote:
> >> The vulnerabilities shown in the SLOTH paper were based on the fact
> >> that implementations still allow MD5 for authentication/integrity
> >> protection, even if (for example) it's explicitly disabled in the
> >> config. So the problem wasn't a fault in the protocol, it's buggy
> >> implementations (as it was for ones that allowed 512-bit keys,
> >> non-prime primes,>> 
> >>  and so on).  Throwing out TLS 1.1 based on this seems rather
> >>  premature.
> Actually no, the TLSv1.2 made a few terribly braindead design choices
>   - newly introduce raw md5RSA digital signatures into TLSv1.2 in 2008
> where all prior TLS protocol versions, including SSLv3 had been using
> the concatenation SHA-1||MD5
>   - making the sha1RSA rather than sha256RSA digital signature
> algorithm the default and mandatory-to-implement algorithm for use
> with TLSv1.2(!!) although it was well-known weaker than the algorithm
> (SHA-1||MD5) in all earlier TLS protocol versions, including SSLv3,
> and in spite of SHA-1 already being officially scheduled for
> end-of-life 2 years later (NIST, SP800-57 pt.1 rev2)
> This is ridiculous considering that SHA-256 is mandatory-to-use
> in the TLSv1.2 PRF.
>   - failing to adjust the truncation of the HMAC output in the
> TLSv1.2 Finished handshake message to be at least half the size of
> the underlying hash function (SHA-256), see RFC 2104 Section 5:
> 
> https://tools.ietf.org/html/rfc2104#section-5

the problem stems from the fact that the same field is used for 
announcing support for signatures in ServerKeyExchange *and* for 
certificates provided by server.

while SKE signatures could have easily been made mandatory to SHA-256 at 
least, the depreciation of SHA-1 signatures for certificates certainly 
wasn't possible at the time - only now we are closing on migration from 
them

so, it was a _bad_ decision, but calling it a "braindead" one is a bit 
over the top, sorry
-- 
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] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Peter Gutmann]

Karthikeyan Bhargavan  writes:

>Coming back to digital signatures, all uses of weak hash functions are
>essentially broken.

Not necessarily.  Use of weak hash functions where the attacker has time to do
offline precomputations/calculations are essentially broken.  I'm not saying
"keep on using MD5", but unless your attacker can find collisions in real time
you're still OK while you take time to switch to SHA-2 or whatever.

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

Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Hubert Kario]

On Monday 11 January 2016 17:28:33 Bill Frantz wrote:
> On 1/11/16 at 4:32 PM, watsonbl...@gmail.com (Watson Ladd) wrote:
> >Do the RFCs require the relevant checks or not? And given that
> >implementations frequently get these sorts of things wrong, how do we
> >make the standard robust against it?
> 
> The best way I can think of is to test to see if the checks are
> being done. For example, if a implementation is supposed to
> check if a number is prime, send a non-prime and see if it takes
> the correct action.
> 
> Publicly available test suites would be a good step toward
> implementing this strategy.

shameful plug: https://github.com/tomato42/tlsfuzzer and the underlying 
https://github.com/tomato42/tlslite-ng

-- 
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] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

[Simon Josefsson]

Adam Langley  writes:

> Curve25519, as the name suggests, operates on 255-bit numbers. When
> encoded as bytes, there's obviously a 256th bit that needs to be
> specified.
>
> Curve25519 implementations didn't set the bit but did used to vary on
> how they parsed it. Some would take a 256-bit number and reduce it
> while others would ignore the bit completely.
>
> However, I believe that implementations have converged on ignoring it.
> That behaviour is specified in draft-irtf-cfrg-curves and tested via
> the test vectors.
>
> Currently https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
> says that implementations SHOULD reject inputs with the high-bit set.
> I think that should be dropped. The X25519 function is specified in
> terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec
> should just use that draft.

I agree.

/Simon


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joe Salowey]

Whoops, thanks for the correction.  It should be the code point assignment in 
draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448, Ed25519 and Ed448. 

Thanks,

Joe





On 1/12/16, 6:24 AM, "Simon Josefsson"  wrote:

>Adam Langley  writes:
>
>> Curve25519, as the name suggests, operates on 255-bit numbers. When
>> encoded as bytes, there's obviously a 256th bit that needs to be
>> specified.
>>
>> Curve25519 implementations didn't set the bit but did used to vary on
>> how they parsed it. Some would take a 256-bit number and reduce it
>> while others would ignore the bit completely.
>>
>> However, I believe that implementations have converged on ignoring it.
>> That behaviour is specified in draft-irtf-cfrg-curves and tested via
>> the test vectors.
>>
>> Currently 
>> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
>> says that implementations SHOULD reject inputs with the high-bit set.
>> I think that should be dropped. The X25519 function is specified in
>> terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec
>> should just use that draft.
>
>I agree.
>
>/Simon
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] MD5 diediedie (was Re: Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms)

[Dave Garrett]

On Tuesday, January 12, 2016 06:05:05 am Stephen Farrell wrote:
> A few notes on this:
> 
> - Calling for the IETF to do something isn't how it works. People
> who want thing X to be done need to write the draft and then see
> if it gets support. I suspect an md5-die-die-die draft would get
> quite a bit of support but...

I'm just bringing up the idea to see what kind of support there is. I don't 
particularly want to write up a draft in full on my own without discussing it 
first.

> - The points Victor made about long-term stored data are valid.
> In various cases it simply wouldn't be a good plan to re-encrypt
> or re-sign old data. Yes, that stored data may not be as secure
> as it once was, but it may be impractical to re-encrypt it all.
> The openpgp wg [1] are dealing with this particular issue as they
> work to do updates, so feel free to get involved in that debate
> there if it's of interest.

Yes, decryption of long term storage would have to be one notable exception. 
The main concern is is with real time (or near) security protocols like TLS, 
SSH, & etc.

It's also important to note that just because we shouldn't be doing obsolete 
and risky things in modern software, that doesn't mean that old software (even 
if maintained) shouldn't be allowed to exist at all. However, doing both in the 
same application has proven to be very dangerous. On the client side, having 
separate legacy clients with no modern support and modern clients with no 
legacy support would drastically improve security, not to mention force users 
to actively acknowledge when they're doing something risky. (yes, the server 
side isn't as simple, nor is this always viable on the client side, either)

> - If your envisaged scope is for all IETF protocols, then I'm sad
> to say there may be "fun" ahead wrt TCP-MD5 [2] which some routing
> folks just won't let die it seems, even though we formally obsoleted
> that [3] 5 years ago. (And yes, that really is sad.)

Yeah... stuff like that is why I kinda don't want to write up a whole draft to 
change the world on my own. ;)

> - Lastly, and again if your envisaged scope is to deprecate MD5 for
> all IETF protocols then that might better fit the charter of the new
> curdle wg. [4] And your draft might be an update to RFC6151 [5] I
> guess, depending on how you wrote it.
> 
> So by all means, write the draft and post a link to the curdle
> list (maybe cc'ing this).

Yes, I am aware of the new CURDLE WG. Brining up the idea here first simply 
made more sense, as MD5 was already coming up in discussion here again. Rich 
Salz also suggested CURDLE being the ideal place to deal with this topic, and I 
don't disagree. Near as I can tell, though, TLS isn't directly within its 
charter and a consensus on what to do for it would have to come out of the TLS 
WG first before CURDLE would be able to include it in any widespread MD5 I-D.

> Cheers,
> S.
> 
> [1] https://tools.ietf.org/wg/openpgp/
> [2] https://tools.ietf.org/html/rfc2385
> [3] https://tools.ietf.org/html/rfc5925
> [4] https://tools.ietf.org/wg/curdle
> [5] https://tools.ietf.org/html/rfc6151


Dave

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

Re: [TLS] Fixing TLS

[Dave Garrett]

On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
> Martin's comment reminded me of the following that I've been meaning to
> post...
> 
> In a recent discussion among some crypto folks, the topic of what TLS 1.3
> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
> centered around the fact that we already have lots of analysis done for TLS
> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
> problems while being as compatible as possible with existing infrastructure.
> So what this would do is take existing security analysis applied to TLS,
[...]

Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.

I'll be the bearer of bad news and tell you that your proposal has come up in 
multiple forms. I suggested a similar thing a while back and far before me 
others have as well. The chairs have, however, long declared consensus that we 
want to focus on a single new version not leaving out other more complex 
changes, namely latency improvements. The primary argument is that TLS version 
adoption rates are horrible and we would be far better suited to one major 
upgrade rather than incremental changes that would likely inhibit adoption of 
the more complex changes that we also need. (just a quick summary from my view; 
someone else can chime in here if they need to)

I can't dispute this position, though personally I think it's not the best 
move. That said, if we were going to do a more incremental TLS version, doing 
it along side HTTP/2 to avoid the messy TLS restrictions it ended up with would 
have been the way to go. That ship has sailed, and we're now well into TLS 1.3 
development, so I guess I'm now on board with working to finalize the work that 
we're already doing (frankly, with a rename to TLS 2.0 being a good idea). If 
you can somehow drum up consensus to overturn the previous consensus, more 
power to you, but I think that's not likely to be the best route anymore.


Dave

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

Re: [TLS] Fixing TLS

[Yoav Nir]

Hi, Peter

Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) that 
this WG is working on right now, why?

Other groups are not working on HTTP/1.2 or IKEv1.1 or any other 
$protocolv$(major-1).$(minor+1).

Any TLS library that exists now doesn’t have an implementation of either “your” 
TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to get an upgraded version 
of your favorite library. So the upgrade path is no smoother for either 
protocol.   If this had been brought up before the work on the current draft 
started, maybe we would be convinced. As it is, I don’t see the point.

Yoav


> On 12 Jan 2016, at 4:03 PM, Peter Gutmann  wrote:
> 
> Martin's comment reminded me of the following that I've been meaning to
> post...
> 
> In a recent discussion among some crypto folks, the topic of what TLS 1.3
> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
> centered around the fact that we already have lots of analysis done for TLS
> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
> problems while being as compatible as possible with existing infrastructure.
> So what this would do is take existing security analysis applied to TLS,
> namely:
> 
> Bhargavan et al, "Proving the TLS handshake secure (as is)".
> 
> Brzuska et al, "Less is more: relaxed yet compatible security notions for key
> exchange".
> 
> Dowling et al, "Modelling ciphersuite and version negotiation in the TLS
> protocol".
> 
> Firing, "Analysis of the Transport Layer Security protocol".
> 
> Gajek et al, "Universally Composable Security Analysis of TLS".
> 
> Giesen et al, "On the security of TLS renegotiation".
> 
> Jager et al, "On the security of TLS-DHE in the standard model".
> 
> Krawczyk et al, "On the security of the TLS protocol".
> 
> (and probably several more) and use them to simplify TLS 1.2 to create an
> improved TLS that leverages about 15 years of analysis, rather than creating
> what's almost a new protocol based on bleeding-edge/experimental ideas,
> mechanisms, and algorithms.
> 
> The discussion started out somewhat informally so by the time it got really
> interesting it was too late to take notes, but I thought I'd try and recreate
> the design points...
> 
> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
> HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
> SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
> instead of GCM as the AEAD if it were freely available).
> 
> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as
> well).
> 
> - Get rid of the IPsec cargo-cult MAC truncation.
> 
> - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
> allow verification (for those who don't have a copy of X9.42, it requires
> the same verification steps as FIPS 186 does).  Also, mix the hash of the
> DHE values into the computed premaster secret to protect against use of
> manipulated curves.
> 
> - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
> done as encode-then-compare, which fixes all known padding-manipulation
> issues).
> 
> - No compression or rehandshake.
> 
> - Replace the PRF with HKDF?  (No pressing need for this, but it would be part
> of the general cleanup).
> 
> Longer discussion points:
> 
> - The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
> between server-specified ephemeral parameters and IETF-blessed fixed ones.
> Arguments can be made either way, we had de facto IETF-blessed fixed DHE
> params in the form of the RFC 2409 ones, but that wasn't such a good idea.
> OTOH with ephemeral DHE params many implementations didn't check them, but
> then the spec never required any checking (or much of anything at all in
> regard to DHE use, which no doubt contributed to some of the dubious
> practices that have been found in the wild).  The situation wasn't helped by
> the use of the PKCS #3 representation, which the requirement to use the
> X9.42 form alongside the accompanying checks attempts to address.
> 
> - Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
> ones are obviously better (for various values of better, see endless debates
> elsewhere), but some people will insist on only using something that's come
> from NIST (I'll reserve my opinion on that one, and wouldn't dream of
> stooping to phrases like "cargo cult protocol design"...).
> 
> Peter.
> ___
> 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] Fixing TLS

[Ilari Liusvaara]

On Tue, Jan 12, 2016 at 02:03:53PM +, Peter Gutmann wrote:
> Martin's comment reminded me of the following that I've been meaning to
> post...
> 
> In a recent discussion among some crypto folks, the topic of what TLS 1.3
> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
> centered around the fact that we already have lots of analysis done for TLS
> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
> problems while being as compatible as possible with existing infrastructure.
> So what this would do is take existing security analysis applied to TLS,
> namely:

Don't forget that there is lots of "features" that are security
problems to deprecate. And that alone creates problems with software
trying to use those.
 
> (and probably several more) and use them to simplify TLS 1.2 to create an
> improved TLS that leverages about 15 years of analysis, rather than creating
> what's almost a new protocol based on bleeding-edge/experimental ideas,
> mechanisms, and algorithms.

Bleeding edge ideas? They essentially re-invented SIGMA, which is over
10 years old. The basic framework for doing 0-RTT is the obvious one.
The only new algorithm prsent since TLS 1.2 is HKDF, which is just 5
years old. 

So I don't see anything "experimential" ideas, mechanisms or algorithms
in there
 
> The discussion started out somewhat informally so by the time it got really
> interesting it was too late to take notes, but I thought I'd try and recreate
> the design points...
> 
> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
>   HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
>   SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
>   instead of GCM as the AEAD if it were freely available).

DHE has serious problems. While the present TLS 1.3 way of doing DHE
isn't totally horrible, advertise DHE and you can get downnegotiation to
TLS 1.2 DHE, and now you are screwed.

Also, AES-CBC has multitude of problems. And they actually dropped most of
the ciphersuites.

> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as
>   well).

Easier to define everything in terms of AEAD mode. Making generic
composition AES-CBC+HMAC-SHA2 isn't as easy as it seems (even pro
cryptographers may not get that right).

> - Get rid of the IPsec cargo-cult MAC truncation.

Finished hashes are no longer truncated (which turned to be a security 
problem).
 
> - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
>   allow verification (for those who don't have a copy of X9.42, it requires
>   the same verification steps as FIPS 186 does).  Also, mix the hash of the
>   DHE values into the computed premaster secret to protect against use of
>   manipulated curves.

The needed checks at that length are just too slow for realtime.

> - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
>   done as encode-then-compare, which fixes all known padding-manipulation
>   issues).

Well, the server sig for RSA is RSA-PSS (the recommendation about encode-
and-compare isn't the tho).

> - No compression or rehandshake.

They dropped those.

> - Replace the PRF with HKDF?  (No pressing need for this, but it would be part
>   of the general cleanup).

They replaced it with just that.

> Longer discussion points:
> 
> - The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
>   between server-specified ephemeral parameters and IETF-blessed fixed ones.
>   Arguments can be made either way, we had de facto IETF-blessed fixed DHE
>   params in the form of the RFC 2409 ones, but that wasn't such a good idea.
>   OTOH with ephemeral DHE params many implementations didn't check them, but
>   then the spec never required any checking (or much of anything at all in
>   regard to DHE use, which no doubt contributed to some of the dubious
>   practices that have been found in the wild).  The situation wasn't helped by
>   the use of the PKCS #3 representation, which the requirement to use the
>   X9.42 form alongside the accompanying checks attempts to address.

Dubious? I would say downright insecure (including some I would say F
grade in SSL labs is too generous).

> - Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
>   ones are obviously better (for various values of better, see endless debates
>   elsewhere), but some people will insist on only using something that's come
>   from NIST (I'll reserve my opinion on that one, and wouldn't dream of
>   stooping to phrases like "cargo cult protocol design"...).

There's also Brainpool (if you want to burn CPU, those are just
inefficient). :-)


-Ilari

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

Re: [TLS] Fixing TLS

[Peter Bowen]

On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett  wrote:
> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>> Martin's comment reminded me of the following that I've been meaning to
>> post...
>>
>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path 
>> from
>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
>> centered around the fact that we already have lots of analysis done for TLS
>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
>> problems while being as compatible as possible with existing infrastructure.
>> So what this would do is take existing security analysis applied to TLS,
> [...]
>
> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.
>
> I'll be the bearer of bad news and tell you that your proposal has come up in 
> multiple forms. I suggested a similar thing a while back and far before me 
> others have as well. The chairs have, however, long declared consensus that 
> we want to focus on a single new version not leaving out other more complex 
> changes, namely latency improvements.

Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter
way to go to document a profile of TLS 1.2 that covers almost all of
this.  From a quick read, existing RFCs and I-Ds cover most of this:
- RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256)
- RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256)
- RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
- RFC 7366 (EtM)
- RFC 7627 (extended master secret)
- RF 4055 (RSA-PSS)

The gaps seem to be:
- No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
(BoringSSL has an implementation using cipher suite 0xca,0xfe)
- DH parameters -- the alternative would be using FFDH named groups
(draft-ietf-tls-negotiated-ff-dhe-10), right?

This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right?

Thanks,
Peter

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

Re: [TLS] Fixing TLS

[Watson Ladd]

On Tue, Jan 12, 2016 at 9:13 AM, Yoav Nir  wrote:
> Hi, Peter
>
> Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) 
> that this WG is working on right now, why?
>
> Other groups are not working on HTTP/1.2 or IKEv1.1 or any other 
> $protocolv$(major-1).$(minor+1).
>
> Any TLS library that exists now doesn’t have an implementation of either 
> “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to get an 
> upgraded version of your favorite library. So the upgrade path is no smoother 
> for either protocol.   If this had been brought up before the work on the 
> current draft started, maybe we would be convinced. As it is, I don’t see the 
> point.

Not if TLS 1.2.1 is a subset of TLS 1.2, similar to the UTA profile.
In fact, that's what happened the last time this idea was raised: it
got kicked over to UTA.

>
> Yoav
>
>
>> On 12 Jan 2016, at 4:03 PM, Peter Gutmann  wrote:
>>
>> Martin's comment reminded me of the following that I've been meaning to
>> post...
>>
>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path 
>> from
>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
>> centered around the fact that we already have lots of analysis done for TLS
>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
>> problems while being as compatible as possible with existing infrastructure.
>> So what this would do is take existing security analysis applied to TLS,
>> namely:
>>
>> Bhargavan et al, "Proving the TLS handshake secure (as is)".
>>
>> Brzuska et al, "Less is more: relaxed yet compatible security notions for key
>> exchange".
>>
>> Dowling et al, "Modelling ciphersuite and version negotiation in the TLS
>> protocol".
>>
>> Firing, "Analysis of the Transport Layer Security protocol".
>>
>> Gajek et al, "Universally Composable Security Analysis of TLS".
>>
>> Giesen et al, "On the security of TLS renegotiation".
>>
>> Jager et al, "On the security of TLS-DHE in the standard model".
>>
>> Krawczyk et al, "On the security of the TLS protocol".
>>
>> (and probably several more) and use them to simplify TLS 1.2 to create an
>> improved TLS that leverages about 15 years of analysis, rather than creating
>> what's almost a new protocol based on bleeding-edge/experimental ideas,
>> mechanisms, and algorithms.
>>
>> The discussion started out somewhat informally so by the time it got really
>> interesting it was too late to take notes, but I thought I'd try and recreate
>> the design points...
>>
>> - Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
>> HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
>> SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
>> instead of GCM as the AEAD if it were freely available).
>>
>> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as
>> well).
>>
>> - Get rid of the IPsec cargo-cult MAC truncation.
>>
>> - For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
>> allow verification (for those who don't have a copy of X9.42, it requires
>> the same verification steps as FIPS 186 does).  Also, mix the hash of the
>> DHE values into the computed premaster secret to protect against use of
>> manipulated curves.
>>
>> - RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
>> done as encode-then-compare, which fixes all known padding-manipulation
>> issues).
>>
>> - No compression or rehandshake.
>>
>> - Replace the PRF with HKDF?  (No pressing need for this, but it would be 
>> part
>> of the general cleanup).
>>
>> Longer discussion points:
>>
>> - The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
>> between server-specified ephemeral parameters and IETF-blessed fixed ones.
>> Arguments can be made either way, we had de facto IETF-blessed fixed DHE
>> params in the form of the RFC 2409 ones, but that wasn't such a good idea.
>> OTOH with ephemeral DHE params many implementations didn't check them, but
>> then the spec never required any checking (or much of anything at all in
>> regard to DHE use, which no doubt contributed to some of the dubious
>> practices that have been found in the wild).  The situation wasn't helped by
>> the use of the PKCS #3 representation, which the requirement to use the
>> X9.42 form alongside the accompanying checks attempts to address.
>>
>> - Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
>> ones are obviously better (for various values of better, see endless debates
>> elsewhere), but some people will insist on only using something that's come
>> from NIST (I'll reserve my opinion on that one, and wouldn't dream of
>> stooping to phrases like "cargo cult protocol design"...).
>>
>> Peter.
>> ___
>> TLS mailing list
>> TLS@ietf.org

Re: [TLS] Fixing TLS

[Eric Rescorla]

On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara 
wrote:
>
> > - Drop 99% of all cipher suites, leaving one traditional one (DHE +
> AES-CBC +
> >   HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM +
> HMAC-
> >   SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference
> for OCB
> >   instead of GCM as the AEAD if it were freely available).
>
> DHE has serious problems. While the present TLS 1.3 way of doing DHE
> isn't totally horrible, advertise DHE and you can get downnegotiation to
> TLS 1.2 DHE, and now you are screwed.
>

Nit: this shouldn't be possible with the anti-downgrade mechanism that was
introduced
in draft-11 because the server's signature will cover the random value. If
you area
aware of an issue here, I would appreciate more information.

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

Re: [TLS] Fixing TLS

[Peter Bowen]

On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen  wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett  wrote:
>> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>>> Martin's comment reminded me of the following that I've been meaning to
>>> post...
>>>
>>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>>> could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path 
>>> from
>>> TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The 
>>> discussion
>>> centered around the fact that we already have lots of analysis done for TLS
>>> 1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
>>> problems while being as compatible as possible with existing infrastructure.
>>> So what this would do is take existing security analysis applied to TLS,
>> [...]
>>
>> Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.
>>
>> I'll be the bearer of bad news and tell you that your proposal has come up 
>> in multiple forms. I suggested a similar thing a while back and far before 
>> me others have as well. The chairs have, however, long declared consensus 
>> that we want to focus on a single new version not leaving out other more 
>> complex changes, namely latency improvements.
>
> Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter
> way to go to document a profile of TLS 1.2 that covers almost all of
> this.  From a quick read, existing RFCs and I-Ds cover most of this:
> - RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256)
> - RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256)
> - RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
> - RFC 7366 (EtM)
> - RFC 7627 (extended master secret)
> - RF 4055 (RSA-PSS)
>
> The gaps seem to be:
> - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> (BoringSSL has an implementation using cipher suite 0xca,0xfe)

Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite.
Still no cipher suite allocated, but there is an active draft.

> - DH parameters -- the alternative would be using FFDH named groups
> (draft-ietf-tls-negotiated-ff-dhe-10), right?
>
> This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right?
>
> Thanks,
> Peter

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

Re: [TLS] Fixing TLS

[Dave Garrett]

On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote:
> On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen  wrote:
> > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> > (BoringSSL has an implementation using cipher suite 0xca,0xfe)
> 
> Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite.
> Still no cipher suite allocated, but there is an active draft.

I have a short WIP PR for integrating these suites into the TLS 1.3 draft 
sitting on GitHub, by the way.

https://github.com/tlswg/tls13-spec/pull/381

Unless I'm misunderstanding the procedure here, though, that draft needs to 
progress to WG adoption before we're ready for it here. (hence the WIP label)


Dave

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

Re: [TLS] Fixing TLS

[Eric Rescorla]

On Tue, Jan 12, 2016 at 10:06 AM, Dave Garrett 
wrote:

> On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote:
> > On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen  wrote:
> > > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> > > (BoringSSL has an implementation using cipher suite 0xca,0xfe)
> >
> > Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite.
> > Still no cipher suite allocated, but there is an active draft.
>
> I have a short WIP PR for integrating these suites into the TLS 1.3 draft
> sitting on GitHub, by the way.
>
> https://github.com/tlswg/tls13-spec/pull/381
>
> Unless I'm misunderstanding the procedure here, though, that draft needs
> to progress to WG adoption before we're ready for it here. (hence the WIP
> label)


This matches my understanding of the policy.

-Ekr


>
>
> Dave
>
> ___
> 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] Fixing TLS

[Ilari Liusvaara]

On Tue, Jan 12, 2016 at 09:41:26AM -0800, Eric Rescorla wrote:
> On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara 
> wrote:
> >
> > DHE has serious problems. While the present TLS 1.3 way of doing DHE
> > isn't totally horrible, advertise DHE and you can get downnegotiation to
> > TLS 1.2 DHE, and now you are screwed.
> >
> 
> Nit: this shouldn't be possible with the anti-downgrade mechanism that was
> introduced
> in draft-11 because the server's signature will cover the random value. If
> you area
> aware of an issue here, I would appreciate more information.

Won't help here, since the server just doesn't support TLS 1.3. The
issue isn't that TLS 1.2 was negotiated, it is that the client is now
faced with old-style DHE.



-Ilari

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

Re: [TLS] Fixing TLS

[David Benjamin]

On Tue, Jan 12, 2016 at 12:27 PM Peter Bowen  wrote:

> The gaps seem to be:
> - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> (BoringSSL has an implementation using cipher suite 0xca,0xfe)
>

0xca,0xfe has since been removed as nothing was using it. I'm not aware of
anything that ever shipped with it enabled.
https://boringssl.googlesource.com/boringssl/+/1feb42a2fbbd8c1a1ed945edb5836d69f7241cda

David


> - DH parameters -- the alternative would be using FFDH named groups
> (draft-ietf-tls-negotiated-ff-dhe-10), right?
>
> This would only leave "Get rid of the IPsec cargo-cult MAC truncation",
> right?
>
> Thanks,
> Peter
>
> ___
> 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] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

[Simon Josefsson]

The same concern still applies: what does it mean to allocate code
point for the 4492bis-05 description?  The document currently says to
reject invalid ECDH keys, but I believe we want to remove that text.  We
could ask Yoav to issue a 4492bis-06 quickly that fix this issue, and
then proceed with early code point allocation.

Further, I believe allocating code points for Ed25519/Ed448 is premature
since 1) the CFRG draft on Ed448 is not updated, and 2) 4492bis-05 does
not contain sufficient detail to implement EdDSA authentication in TLS.
See draft-josefsson-tls-eddsa2-02 for some discussion to make EdDSA
work in TLS, as it relates to PKIX handling as well.

To be clear: I support allocating a code point for X25519 as described
in 4492bis with the relaxed public key check.

/Simon

> Whoops, thanks for the correction.  It should be the code point
> assignment in draft-ietf-tls-rfc4492bis-05 for Curve25519, Curve448,
> Ed25519 and Ed448. 
> 
> Thanks,
> 
> Joe
> 
> 
> 
> 
> 
> On 1/12/16, 6:24 AM, "Simon Josefsson"  wrote:
> 
> >Adam Langley  writes:
> >
> >> Curve25519, as the name suggests, operates on 255-bit numbers. When
> >> encoded as bytes, there's obviously a 256th bit that needs to be
> >> specified.
> >>
> >> Curve25519 implementations didn't set the bit but did used to vary
> >> on how they parsed it. Some would take a 256-bit number and reduce
> >> it while others would ignore the bit completely.
> >>
> >> However, I believe that implementations have converged on ignoring
> >> it. That behaviour is specified in draft-irtf-cfrg-curves and
> >> tested via the test vectors.
> >>
> >> Currently
> >> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
> >> says that implementations SHOULD reject inputs with the high-bit
> >> set. I think that should be dropped. The X25519 function is
> >> specified in terms of bytes in draft-irtf-cfrg-curves and I think
> >> the TLS spec should just use that draft.
> >
> >I agree.
> >
> >/Simon



pgpGdq_Ci4QGN.pgp
Description: OpenPGP digital signatur
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fixing TLS

[Dave Garrett]

On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett 
> wrote:
> > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
> >
> > I'll be the bearer of bad news and tell you that your proposal has come up
> > in multiple forms. I suggested a similar thing a while back and far before
> > me others have as well. The chairs have, however, long declared consensus
> > that we want to focus on a single new version not leaving out other more
> > complex changes, namely latency improvements. The primary argument is that
> > TLS version adoption rates are horrible and we would be far better suited
> > to one major upgrade rather than incremental changes that would likely
> > inhibit adoption of the more complex changes that we also need. (just a
> > quick summary from my view; someone else can chime in here if they need to)
> >
> > I can't dispute this position, though personally I think it's not the best
> > move. That said, if we were going to do a more incremental TLS version,
> > doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up
> > with would have been the way to go. That ship has sailed, and we're now
> > well into TLS 1.3 development, so I guess I'm now on board with working to
> > finalize the work that we're already doing (frankly, with a rename to TLS
> > 2.0 being a good idea). If you can somehow drum up consensus to overturn
> > the previous consensus, more power to you, but I think that's not likely to
> > be the best route anymore.
> 
> I'll just second what David said here.  0-RTT mode is here to stay, and I
> don't see a simple upgrade path from TLS 1.2.  Speed matters, and 0-RTT is
> a huge upgrade for users.  The trick is doing this securely...
> 
> My opinion counts little here, and TLS 1.3 is already nearly completely
> defined, so I think it is too late for this discussion.  However, if it
> were not...
> 
> A clean-slate TLS 2.0 which reuses as little as possible, and simplifies
> life as much as possible, would have been preferable, IMO.  I look at the
> QUIC crypto code and then go back to the TLS/SSL code, and there is a night
> and day difference in complexity.  I think it is going to be painful for
> some of us to watch the simple, clean QUIC crypto code move to the archives
> and get replaced with TLS 1.3, which is surely going to be a substantial
> bolt-on of code to the existing TLS 1.2 code base.  It takes a super-genius
> just to see all the potential pitfalls in the TLS 1.2 code as it is.  I
> think it will be even harder to analyze after the TLS 1.3 bolt-on.
> Fortunately, we seem to have a large number of super-geniuses working in
> TLS, much of the present company on this thread included :)  However, if I
> personally were making changes to the code, it would be maybe 4X faster to
> do it in QUIC crypto, and 4X more likely that I would not introduce a
> critical bug in the process.
> 
> I think it is natural for many members of this email list to discount this
> complexity issue in TLS 1.2/1.3, since many of the most brilliant
> programmers see the existing code as not all that complex.  For regular
> mortal programmers out there like me, we would very much appreciate a
> clean-slate effort with minimal complexity, and there are a lot of lessons
> you folks have learned over the years that could be included.
> 
> Maybe next time, in TLS 1.4? :-p

Personally, I hope this new version of TLS, save for possibly some minor update 
& extensions, is the final version. I hope that Google's efforts to get QUIC 
as-is specced out go quickly and smoothly, and that it can be used as a basis 
to develop an official total TCP/TLS replacement. (the early documentation for 
QUIC was horrible, but the current work is vastly improved) As far as I'm 
concerned, TLS 1.3 is a transitional measure which should only be used in the 
medium-term by those who adopt new tech very slowly, and in the long-term 
phased out entirely. It is a very important transitional measure that needs to 
be done with as high a security and performance as possible, but a finite one 
nonetheless. (well, arguably, pretty much everything is, given a long enough 
timeframe ;) We have to get through the short-term to get to the long-term, 
though.


Dave

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

Re: [TLS] Fixing TLS

[Andrei Popov]

> I hope that Google's efforts to get QUIC as-is specced out go quickly and 
> smoothly, and that it can be used as a basis to develop an official total 
> TCP/TLS replacement.

If this were the path forward (and I doubt that it is), I would very much 
prefer Peter Gutman's evolutionary TLS 1.3.

Cheers,

Andrei

-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Dave Garrett
Sent: Tuesday, January 12, 2016 11:39 AM
To: Bill Cox 
Cc: tls@ietf.org
Subject: Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett 
> wrote:
> > On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
> >
> > I'll be the bearer of bad news and tell you that your proposal has 
> > come up in multiple forms. I suggested a similar thing a while back 
> > and far before me others have as well. The chairs have, however, 
> > long declared consensus that we want to focus on a single new 
> > version not leaving out other more complex changes, namely latency 
> > improvements. The primary argument is that TLS version adoption 
> > rates are horrible and we would be far better suited to one major 
> > upgrade rather than incremental changes that would likely inhibit 
> > adoption of the more complex changes that we also need. (just a 
> > quick summary from my view; someone else can chime in here if they 
> > need to)
> >
> > I can't dispute this position, though personally I think it's not 
> > the best move. That said, if we were going to do a more incremental 
> > TLS version, doing it along side HTTP/2 to avoid the messy TLS 
> > restrictions it ended up with would have been the way to go. That 
> > ship has sailed, and we're now well into TLS 1.3 development, so I 
> > guess I'm now on board with working to finalize the work that we're 
> > already doing (frankly, with a rename to TLS
> > 2.0 being a good idea). If you can somehow drum up consensus to 
> > overturn the previous consensus, more power to you, but I think 
> > that's not likely to be the best route anymore.
> 
> I'll just second what David said here.  0-RTT mode is here to stay, 
> and I don't see a simple upgrade path from TLS 1.2.  Speed matters, 
> and 0-RTT is a huge upgrade for users.  The trick is doing this securely...
> 
> My opinion counts little here, and TLS 1.3 is already nearly 
> completely defined, so I think it is too late for this discussion.  
> However, if it were not...
> 
> A clean-slate TLS 2.0 which reuses as little as possible, and 
> simplifies life as much as possible, would have been preferable, IMO.  
> I look at the QUIC crypto code and then go back to the TLS/SSL code, 
> and there is a night and day difference in complexity.  I think it is 
> going to be painful for some of us to watch the simple, clean QUIC 
> crypto code move to the archives and get replaced with TLS 1.3, which 
> is surely going to be a substantial bolt-on of code to the existing 
> TLS 1.2 code base.  It takes a super-genius just to see all the 
> potential pitfalls in the TLS 1.2 code as it is.  I think it will be even 
> harder to analyze after the TLS 1.3 bolt-on.
> Fortunately, we seem to have a large number of super-geniuses working 
> in TLS, much of the present company on this thread included :)  
> However, if I personally were making changes to the code, it would be 
> maybe 4X faster to do it in QUIC crypto, and 4X more likely that I 
> would not introduce a critical bug in the process.
> 
> I think it is natural for many members of this email list to discount 
> this complexity issue in TLS 1.2/1.3, since many of the most brilliant 
> programmers see the existing code as not all that complex.  For 
> regular mortal programmers out there like me, we would very much 
> appreciate a clean-slate effort with minimal complexity, and there are 
> a lot of lessons you folks have learned over the years that could be included.
> 
> Maybe next time, in TLS 1.4? :-p

Personally, I hope this new version of TLS, save for possibly some minor update 
& extensions, is the final version. I hope that Google's efforts to get QUIC 
as-is specced out go quickly and smoothly, and that it can be used as a basis 
to develop an official total TCP/TLS replacement. (the early documentation for 
QUIC was horrible, but the current work is vastly improved) As far as I'm 
concerned, TLS 1.3 is a transitional measure which should only be used in the 
medium-term by those who adopt new tech very slowly, and in the long-term 
phased out entirely. It is a very important transitional measure that needs to 
be done with as high a security and performance as possible, but a finite one 
nonetheless. (well, arguably, pretty much everything is, given a long enough 
timeframe ;) We have to get through the short-term to get to the long-term, 
though.


Dave

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2

Re: [TLS] Fixing TLS

[Tony Arcieri]

On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox  wrote:

> I wish that were the plan (to upgrade QUIC crypto and eventually make that
> the new crypto platform).  If I am not mistaken, QUICK crypto is going to
> be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the
> transport layer.  So, maybe long-term you folks could do a clean-slate TLS
> 2.0?  That would would be awesome, IMO.
>

Have you looked at OPTLS? It provides a clean "core" for TLS, and also
supports Diffie-Hellman authentication ala Trevor Perrin's protocol Noise.

If TLS 1.3 can shed the cruft, OPTLS seems like a nice direction to go for
"TLS 2.0"

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

Re: [TLS] Fixing TLS

[Eric Rescorla]

On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox  wrote:

> On Tue, Jan 12, 2016 at 11:39 AM, Dave Garrett 
> wrote:
>
>> On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
>>
>> Personally, I hope this new version of TLS, save for possibly some minor
>> update & extensions, is the final version. I hope that Google's efforts to
>> get QUIC as-is specced out go quickly and smoothly, and that it can be used
>> as a basis to develop an official total TCP/TLS replacement. (the early
>> documentation for QUIC was horrible, but the current work is vastly
>> improved) As far as I'm concerned, TLS 1.3 is a transitional measure which
>> should only be used in the medium-term by those who adopt new tech very
>> slowly, and in the long-term phased out entirely. It is a very important
>> transitional measure that needs to be done with as high a security and
>> performance as possible, but a finite one nonetheless. (well, arguably,
>> pretty much everything is, given a long enough timeframe ;) We have to get
>> through the short-term to get to the long-term, though.
>>
>>
>> Dave
>>
>
> I wish that were the plan (to upgrade QUIC crypto and eventually make that
> the new crypto platform).  If I am not mistaken, QUICK crypto is going to
> be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the
> transport layer.
>

This is my understanding as well, based both onconversations with the QUIC
folks, and Adam and Jana's public presentations. A number of us (MT, I,
Jana, Ian, AGL, Christian) have already started some initial conversations
at how to do that.

With that said, I don't think there's a plausible story in which QUIC
becomes the only
transport protocol in the world any time soon, so I don't think standalone
TLS 1.3
is going away.

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

Re: [TLS] Fixing TLS

[Kurt Roeckx]

On Tue, Jan 12, 2016 at 11:27:02AM -0800, Bill Cox wrote:
> 
> I'll just second what David said here.  0-RTT mode is here to stay, and I
> don't see a simple upgrade path from TLS 1.2.  Speed matters, and 0-RTT is
> a huge upgrade for users.  The trick is doing this securely...

And I think because it's seems non-obvious how to get that correct
implementations may delay implementing that part.


Kurt

___
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

[Yoav Nir]

> On 12 Jan 2016, at 9:26 PM, Simon Josefsson  wrote:
> 
> The same concern still applies: what does it mean to allocate code
> point for the 4492bis-05 description?

Allocating code points just means an implementation of draft-05 is likely to 
interoperate just fine with an implementation of the final RFC.

Of course nothing is ever final until the RFC is out, so there’s always a risk 
involved, but it is considered prudent to allocate numbers when we’re 
reasonably certain of the calculations and on-the-wire formats. Any debate 
about whether we should or should not check certain inputs for certain 
conditions need not be a bar for allocating numbers.

Yoav


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fixing TLS

[Dave Garrett]

On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote:
> On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote:
> > I hope that Google's efforts to get QUIC as-is specced out go quickly and 
> > smoothly, and that it can be used as a basis to develop an official total 
> > TCP/TLS replacement.
> 
> If this were the path forward (and I doubt that it is), I would very much 
> prefer Peter Gutman's evolutionary TLS 1.3.

I was just chatting a bit off-list, and apparently I wasn't aware of QUIC's 
latest plans, so it's not as clear as I previously said. Unfortunately, it 
seems that they have yet to actually write anything down (a too frequent 
pattern with QUIC), so I can't really comment on what I'd like to see happen in 
this realm anymore.

In any case, ~whatever~ comes after TLS 1.3 will hopefully have some major 
changes. I have no idea what that will be, but TLS 1.3 comes first. That's a 
discussion for a future time.


Dave

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

Re: [TLS] Fixing TLS

[Eric Rescorla]

On Tue, Jan 12, 2016 at 12:18 PM, Tony Arcieri  wrote:

> On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox  wrote:
>
>> I wish that were the plan (to upgrade QUIC crypto and eventually make
>> that the new crypto platform).  If I am not mistaken, QUICK crypto is going
>> to be archived, TLS 1.3 will replace the crypto code, and QUIC will remain
>> the transport layer.  So, maybe long-term you folks could do a clean-slate
>> TLS 2.0?  That would would be awesome, IMO.
>>
>
> Have you looked at OPTLS? It provides a clean "core" for TLS, and also
> supports Diffie-Hellman authentication ala Trevor Perrin's protocol Noise.
>
> If TLS 1.3 can shed the cruft, OPTLS seems like a nice direction to go for
> "TLS 2.0
>

TLS 1.3 actually takes quite a bit of stuff from OPTLS (as you can see in
the most
recent OPTLS paper). To a great extent, the differences
are due to explicit WG decisions, specifically the following two decisions;

- Not to have an offline-signed DH credential
- To require signing on every public-key-based handshake.

IIRC there was pretty strong consensus for both these decisions, but if
there is
a lot of feeling to the contrary, presumably we could revisit these.

-Ekr

-- 
> Tony Arcieri
>
> ___
> 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] Fixing TLS

[Dave Garrett]

On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote:
> On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox  wrote:
> > I wish that were the plan (to upgrade QUIC crypto and eventually make that
> > the new crypto platform).  If I am not mistaken, QUICK crypto is going to
> > be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the
> > transport layer.
> 
> This is my understanding as well, based both onconversations with the QUIC
> folks, and Adam and Jana's public presentations. A number of us (MT, I,
> Jana, Ian, AGL, Christian) have already started some initial conversations
> at how to do that.

I'm quite interested to hear what the plans are there. I'd appreciate it if, 
whenever there is a fleshed-out starting point, an outline could be posted to 
this list to keep us in the loop with what's going to be the initial design. 
Not necessarily for debate here, but just so we can have an idea of where 
things are going.

> With that said, I don't think there's a plausible story in which QUIC becomes 
> the only
> transport protocol in the world any time soon, so I don't think standalone 
> TLS 1.3
> is going away.

Yes. Whatever the discussion for future work, TLS 1.3 is the current direction. 
One step at a time so we don't trip over our feet. ;)


Dave

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

Re: [TLS] Fixing TLS

[Eric Rescorla]

On Tue, Jan 12, 2016 at 12:33 PM, Dave Garrett 
wrote:

> On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote:
> > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox 
> wrote:
> > > I wish that were the plan (to upgrade QUIC crypto and eventually make
> that
> > > the new crypto platform).  If I am not mistaken, QUICK crypto is going
> to
> > > be archived, TLS 1.3 will replace the crypto code, and QUIC will
> remain the
> > > transport layer.
> >
> > This is my understanding as well, based both onconversations with the
> QUIC
> > folks, and Adam and Jana's public presentations. A number of us (MT, I,
> > Jana, Ian, AGL, Christian) have already started some initial
> conversations
> > at how to do that.
>
> I'm quite interested to hear what the plans are there. I'd appreciate it
> if, whenever there is a fleshed-out starting point, an outline could be
> posted to this list to keep us in the loop with what's going to be the
> initial design. Not necessarily for debate here, but just so we can have an
> idea of where things are going.
>

We definitely would post that somewhere, but thanks for the reminder to
send a pointer
to TLS WG.

-Ekr




>
> > With that said, I don't think there's a plausible story in which QUIC
> becomes the only
> > transport protocol in the world any time soon, so I don't think
> standalone TLS 1.3
> > is going away.
>
> Yes. Whatever the discussion for future work, TLS 1.3 is the current
> direction. One step at a time so we don't trip over our feet. ;)
>
>
> Dave
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Server behavior when client certificate does not match the request ?

[Fabrice Gautier]

Hi,

TLS 1.2 RFC says that a a client certificate MUST be compatible the
parameters specified in the Certificate Request: key type,
hash/signature algorithm and CA.
If a client does not have such a compatible cert, it MUST send an
empty Certificate message.

In practice, what is a common behavior for Servers in the case where
the client sends an incompatible cert ? Treat it as if there was an
empty cert or an invalid cert ? Fail the handshake ?

In practice, is it okay for a client to send a cert that may not be
compatible with the CertificateRequest, knowing that the client cert
might be selected by user action, or by an application layer above the
TLS layer, and knowing that on the server side, the client cert
verification might also be done a different layer, that may actually
have a different idea of what an acceptable cert is than the TLS layer
?


Thanks

-- Fabrice

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

Re: [TLS] Server behavior when client certificate does not match the request ?

[Eric Rescorla]

On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier 
wrote:

> Hi,
>
> TLS 1.2 RFC says that a a client certificate MUST be compatible the
> parameters specified in the Certificate Request: key type,
> hash/signature algorithm and CA.
> If a client does not have such a compatible cert, it MUST send an
> empty Certificate message.
>
> In practice, what is a common behavior for Servers in the case where
> the client sends an incompatible cert ? Treat it as if there was an
> empty cert or an invalid cert ? Fail the handshake ?
>
> In practice, is it okay for a client to send a cert that may not be
> compatible with the CertificateRequest, knowing that the client cert
> might be selected by user action, or by an application layer above the
> TLS layer, and knowing that on the server side, the client cert
> verification might also be done a different layer, that may actually
> have a different idea of what an acceptable cert is than the TLS layer
> ?
>

Would a fair rephrase of this be "How many servers advertise some set of
requirements for CertificateRequest that is actually stricter than what they
would accept"? [0]

-Ekr

[0] The case of "I advertise requirements that are looser than I would
accept"
is, I suspect, quite common. For instance, you might advertise an empty
CA list.



> Thanks
>
> -- Fabrice
>
> ___
> 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] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

[Ilari Liusvaara]

On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:
> 
> > On 12 Jan 2016, at 9:26 PM, Simon Josefsson  wrote:
> > 
> > The same concern still applies: what does it mean to allocate code
> > point for the 4492bis-05 description?
> 
> Allocating code points just means an implementation of draft-05 is
> likely to interoperate just fine with an implementation of the final
> RFC.
> 
> Of course nothing is ever final until the RFC is out, so there’s
> always a risk involved, but it is considered prudent to allocate
> numbers when we’re reasonably certain of the calculations and on-
> the-wire formats. Any debate about whether we should or should not
> check certain inputs for certain conditions need not be a bar for
> allocating numbers.

Assuming CFRG chairs really did declare consensus on Ed448 hash, then
the final characteristics of Ed448 are known and I have a reference
implementation.

And the PKIX draft looks implementable (has wrong example?)

More serious interop hazard is what to do with X25519/X448 and THS
(some of the proposed stuff is not wire-compatible).


-Ilari

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

Re: [TLS] Server behavior when client certificate does not match the request ?

[Fabrice Gautier]

On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla  wrote:
>
>
> On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier 
> wrote:
>>
>> Hi,
>>
>> TLS 1.2 RFC says that a a client certificate MUST be compatible the
>> parameters specified in the Certificate Request: key type,
>> hash/signature algorithm and CA.
>> If a client does not have such a compatible cert, it MUST send an
>> empty Certificate message.
>>
>> In practice, what is a common behavior for Servers in the case where
>> the client sends an incompatible cert ? Treat it as if there was an
>> empty cert or an invalid cert ? Fail the handshake ?
>>
>> In practice, is it okay for a client to send a cert that may not be
>> compatible with the CertificateRequest, knowing that the client cert
>> might be selected by user action, or by an application layer above the
>> TLS layer, and knowing that on the server side, the client cert
>> verification might also be done a different layer, that may actually
>> have a different idea of what an acceptable cert is than the TLS layer
>> ?
>
>
> Would a fair rephrase of this be "How many servers advertise some set of
> requirements for CertificateRequest that is actually stricter than what they
> would accept"? [0]

Yes, that's another way to put it.

Other related questions:
"Do TLS libraries act strictly on those requirements, or do they leave
it to the application layers?"
"How do TLS libraries/server applications act when such requirements
are not respected?"


> -Ekr
>
> [0] The case of "I advertise requirements that are looser than I would
> accept"
> is, I suspect, quite common. For instance, you might advertise an empty
> CA list.

Right,
And I guess servers may also advertise empty hash/sig list, and empty
certificate_types list, although that would be violating the RFC.

>
>>
>> Thanks
>>
>> -- Fabrice
>>
>> ___
>> 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] Server behavior when client certificate does not match the request ?

[Eric Rescorla]

On Tue, Jan 12, 2016 at 1:30 PM, Fabrice Gautier 
wrote:

> On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla  wrote:
> >
> >
> > On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier <
> fabrice.gaut...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> TLS 1.2 RFC says that a a client certificate MUST be compatible the
> >> parameters specified in the Certificate Request: key type,
> >> hash/signature algorithm and CA.
> >> If a client does not have such a compatible cert, it MUST send an
> >> empty Certificate message.
> >>
> >> In practice, what is a common behavior for Servers in the case where
> >> the client sends an incompatible cert ? Treat it as if there was an
> >> empty cert or an invalid cert ? Fail the handshake ?
> >>
> >> In practice, is it okay for a client to send a cert that may not be
> >> compatible with the CertificateRequest, knowing that the client cert
> >> might be selected by user action, or by an application layer above the
> >> TLS layer, and knowing that on the server side, the client cert
> >> verification might also be done a different layer, that may actually
> >> have a different idea of what an acceptable cert is than the TLS layer
> >> ?
> >
> >
> > Would a fair rephrase of this be "How many servers advertise some set of
> > requirements for CertificateRequest that is actually stricter than what
> they
> > would accept"? [0]
>
> Yes, that's another way to put it.
>
> Other related questions:
> "Do TLS libraries act strictly on those requirements, or do they leave
> it to the application layers?"
> "How do TLS libraries/server applications act when such requirements
> are not respected?"
>

I know NSS isn't used in a lot of servers, but at this point I believe that
to a
first order it enforces the same rules that it advertises.

-Ekr




>
> > -Ekr
> >
> > [0] The case of "I advertise requirements that are looser than I would
> > accept"
> > is, I suspect, quite common. For instance, you might advertise an empty
> > CA list.
>
> Right,
> And I guess servers may also advertise empty hash/sig list, and empty
> certificate_types list, although that would be violating the RFC.
>
> >
> >>
> >> Thanks
> >>
> >> -- Fabrice
> >>
> >> ___
> >> 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] Server behavior when client certificate does not match the request ?

[Peter Gutmann]

Fabrice Gautier  writes:

>"Do TLS libraries act strictly on those requirements, or do they leave it to
>the application layers?"
>
>"How do TLS libraries/server applications act when such requirements are not
>respected?"

This has already been discussed in the past, it's not up to TLS to constrain
what a CA can do, and more to the point if you've paid a CA a small fortune
for a cert you don't want some TLS implementation to reject it because of some
minor disagreement over what colour the cert frame is painted.

Redde Caesari quae sunt Caesaris, the PKI code decides whether a cert chain is
acceptable or not, not the TLS code.  

Which is exactly what my code does.

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

Re: [TLS] Server behavior when client certificate does not match the request ?

[Viktor Dukhovni]

On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote:

> In practice, what is a common behavior for Servers in the case where
> the client sends an incompatible cert ? Treat it as if there was an
> empty cert or an invalid cert ? Fail the handshake ?

With TLS 1.0/1.1, in which the server cannot indicate support for
a list signature algorithms, the logical conclusion is that the
client MUST NOT use a public key algorithm that is different from
the agreed cipher-suite.  It can accomplish this by only advertising
cipher suites compatible with the client certificate it will (can
be tricky if it has more than one).

With TLS 1.0/1.1 there is no reason to expect that the server will
understand signatures made with a public key algorithm other than
the one used in the the server certificate (which agrees with the
ciphersuite in the server HELLO).

With TLS 1.2, where the server does send a supported_signature_algorithms
list, clients that use signatures other than those listed should
expect to run into servers that reject this with a fatal alert.
The server's TLS stack (not its X.509 chain verification code) has
to check the signature in the client's "Certifice Verify" message.

The server's list of CA's on the other hand is largely a hint, and
clients often just ignore it entirely.  If the server can verify
the certificate, it generally does not matter whether the CA was
listed in the certificate request message or not.  For many servers
client certificates are optional anyway, or they verify them without
reference to any particular PKI.

-- 
Viktor.

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

Re: [TLS] Server behavior when client certificate does not match the request ?

[Fabrice Gautier]

On Tue, Jan 12, 2016 at 3:53 PM, Viktor Dukhovni  wrote:
> On Tue, Jan 12, 2016 at 01:07:16PM -0800, Fabrice Gautier wrote:
>
>> In practice, what is a common behavior for Servers in the case where
>> the client sends an incompatible cert ? Treat it as if there was an
>> empty cert or an invalid cert ? Fail the handshake ?
>
> With TLS 1.0/1.1, in which the server cannot indicate support for
> a list signature algorithms, the logical conclusion is that the
> client MUST NOT use a public key algorithm that is different from
> the agreed cipher-suite.  It can accomplish this by only advertising
> cipher suites compatible with the client certificate it will (can
> be tricky if it has more than one).

> With TLS 1.0/1.1 there is no reason to expect that the server will
> understand signatures made with a public key algorithm other than
> the one used in the the server certificate (which agrees with the
> ciphersuite in the server HELLO).

Hum, the client certificate type would theoretically defined by the
"certificate_types" list in the CertificateRequest message, not the
cipher suite.

So you can have RSA client cert with EC ciphersuites and server certs
and vice-versa, even in TLS 1.0/1.1


> With TLS 1.2, where the server does send a supported_signature_algorithms
> list, clients that use signatures other than those listed should
> expect to run into servers that reject this with a fatal alert.
> The server's TLS stack (not its X.509 chain verification code) has
> to check the signature in the client's "Certifice Verify" message.

Which does raise another interesting question when certificate_types
and supported_signature_algorithms conflicts.


> The server's list of CA's on the other hand is largely a hint, and
> clients often just ignore it entirely.  If the server can verify
> the certificate, it generally does not matter whether the CA was
> listed in the certificate request message or not.  For many servers
> client certificates are optional anyway, or they verify them without
> reference to any particular PKI.
>
> --
> Viktor.
>
> ___
> 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] Server behavior when client certificate does not match the request ?

[Eric Rescorla]

On Tue, Jan 12, 2016 at 4:13 PM, Fabrice Gautier 
wrote:

>
> > With TLS 1.2, where the server does send a supported_signature_algorithms
> > list, clients that use signatures other than those listed should
> > expect to run into servers that reject this with a fatal alert.
> > The server's TLS stack (not its X.509 chain verification code) has
> > to check the signature in the client's "Certifice Verify" message.
>
> Which does raise another interesting question when certificate_types
> and supported_signature_algorithms conflicts.


It's the intersection:

https://tools.ietf.org/html/rfc5246#section-7.4.4

   -  Any certificates provided by the client MUST be signed using a
  hash/signature algorithm pair found in
  supported_signature_algorithms.

   -  The end-entity certificate provided by the client MUST contain a
  key that is compatible with certificate_types.  If the key is a
  signature key, it MUST be usable with some hash/signature
  algorithm pair in supported_signature_algorithms.

However, it's confusing, and so we removed certificate_types in 1.3.

-Ekr



>
> > The server's list of CA's on the other hand is largely a hint, and
> > clients often just ignore it entirely.  If the server can verify
> > the certificate, it generally does not matter whether the CA was
> > listed in the certificate request message or not.  For many servers
> > client certificates are optional anyway, or they verify them without
> > reference to any particular PKI.
> >
> > --
> > Viktor.
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fixing TLS

[Peter Gutmann]

Yoav Nir  writes:

>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
>that this WG is working on right now, why?

Embedded devices and similar systems with long-term requirements.  Most of my
user base is embedded (or non-embedded equivalents, systems that need to run
in a fixed configuration for a very long time after they're deployed).  As
I've mentioned in an earlier post, the median point on the bell curve is
probably around TLS 1.0/1.1.  These are systems with an expected lifetime of
10-20 years or more, deployment of new versions moves slowly and carefully so
the less radical changes you need to make the better, and most importantly you
can't roll out patches every month or two when the next attack on TLS is
published.

To expand on this, I'll take Ilari Liusvaara's comments:

>Bleeding edge ideas? They essentially re-invented SIGMA, which is over 10
>years old. The basic framework for doing 0-RTT is the obvious one. The only
>new algorithm prsent since TLS 1.2 is HKDF, which is just 5 years old.
>
>So I don't see anything "experimential" ideas, mechanisms or algorithms in
>there

When SSLv3 was introduced, it also used ideas that were 10-20 years old (DH,
RSA, DES, etc, only SHA-1 was relatively new).  They were mature algorithms,
lots of research had been published on them, and yet we're still fixing issues
with them 20 years later (DH = 1976, SSLv3 = 1996, Logjam = 2015).

TLS 2.0-called-1.3 will roll back the 20 years of experience we have with all
the things that can go wrong and start again from scratch.  SIGMA, at ten
years old, is a relative newcomer to DH's 20 years when it was used in SSLv3,
but in either case we didn't discover all the problems with it until after the
protocol that used it was rolled out.  We currently have zero implementation
and deployment experience with 2.0-called-1.3 [0], which means we're likely to
have another 10-20 years of patching holes ahead of us.  This is what I meant
by "experimental, bleeding-edge".

What TLS 1.3-which-is-1.3 should be is an LTS version that's essentially
what's already out there with the bugs fixed, and where you've got a pretty
good chance that you won't be rolling out hotfixes every other month to patch
the newly-discovered-vulnerability of the month (which, in the case of most
things that aren't web browsers and servers, is more or less impossible to
do).

(Which also means that the requirements for it should include explicit "don't
use MD5, don't use keys < 1024 bits, don't precompute DH and reuse the
values", all the other obvious-but-apparently-not-obvious-enough stupid that's
turned up recently).

TLS 2.0-called-1.3 seems to be doing the same thing that HTTPS 2 did,
targeting the specialised requirements of web servers/browsers and ignoring
everything else.  The HTTPS 2 WG's response to this at the time was "let them
eat HTTP 1.1", so that you've now got HTTP-for-Google (2.0) and HTTP-for-
everything-else (1.1).  Is the TLS equivalent going to be "let them eat TLS
1.1"?

(General note: That one short post has generated an enormous amount of email
 off-list as well as on, for all those waiting for replies to private mail,
 please be patient, I'm working through it...).

Peter.

[0] This all feels somewhat biblical, "you are 2.0 son of 1.2, but you will be
known as 1.3".
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fixing TLS

[Watson Ladd]

On Tue, Jan 12, 2016 at 5:12 PM, Peter Gutmann
 wrote:
> Yoav Nir  writes:
>
>>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
>>that this WG is working on right now, why?
>
> Embedded devices and similar systems with long-term requirements.  Most of my
> user base is embedded (or non-embedded equivalents, systems that need to run
> in a fixed configuration for a very long time after they're deployed).  As
> I've mentioned in an earlier post, the median point on the bell curve is
> probably around TLS 1.0/1.1.  These are systems with an expected lifetime of
> 10-20 years or more, deployment of new versions moves slowly and carefully so
> the less radical changes you need to make the better, and most importantly you
> can't roll out patches every month or two when the next attack on TLS is
> published.

So for your proposal to solve this problem, it needs to be more likely
to be secure then TLS 1.3. Of course, the slow rollout gives time to
thoroughly test massive changes, while large numbers of small changes
will not be a good idea.

>
> To expand on this, I'll take Ilari Liusvaara's comments:
>
>>Bleeding edge ideas? They essentially re-invented SIGMA, which is over 10
>>years old. The basic framework for doing 0-RTT is the obvious one. The only
>>new algorithm prsent since TLS 1.2 is HKDF, which is just 5 years old.
>>
>>So I don't see anything "experimential" ideas, mechanisms or algorithms in
>>there
>
> When SSLv3 was introduced, it also used ideas that were 10-20 years old (DH,
> RSA, DES, etc, only SHA-1 was relatively new).  They were mature algorithms,
> lots of research had been published on them, and yet we're still fixing issues
> with them 20 years later (DH = 1976, SSLv3 = 1996, Logjam = 2015).

We all understand that the security of a protocol is not a function
not of the primitives but of the way the protocol works. The confusion
between export and nonexport DH shares was noted almost immediately in
SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a
discovery in 2015, given that the reasons for this were all worked out
in the early 90's. So no, Logjam is not a result of unknown issues
appearing after 20 years, but ignoring known issues.

>
> TLS 2.0-called-1.3 will roll back the 20 years of experience we have with all
> the things that can go wrong and start again from scratch.  SIGMA, at ten
> years old, is a relative newcomer to DH's 20 years when it was used in SSLv3,
> but in either case we didn't discover all the problems with it until after the
> protocol that used it was rolled out.  We currently have zero implementation
> and deployment experience with 2.0-called-1.3 [0], which means we're likely to
> have another 10-20 years of patching holes ahead of us.  This is what I meant
> by "experimental, bleeding-edge".

There is an old joke about the resume with one years experience
repeated 20 times. All of the problems in TLS have been known for
decades, as I've repeatedly demonstrated on this list. All of them
were known to cryptographers at the time TLS was being designed and
deployed. It does not take deployment to trigger analysis.

>
> What TLS 1.3-which-is-1.3 should be is an LTS version that's essentially
> what's already out there with the bugs fixed, and where you've got a pretty
> good chance that you won't be rolling out hotfixes every other month to patch
> the newly-discovered-vulnerability of the month (which, in the case of most
> things that aren't web browsers and servers, is more or less impossible to
> do).

TLS 1.3 is being designed in cooperation with people who *actually
know cryptography* with computer-based models and theorem provers for
the entire protocol. Your proposal isn't, instead patching a
collection of known issues. But we already did that in UTA. I don't
see why we should believe your proposal solves it better.
>
> (Which also means that the requirements for it should include explicit "don't
> use MD5, don't use keys < 1024 bits, don't precompute DH and reuse the
> values", all the other obvious-but-apparently-not-obvious-enough stupid that's
> turned up recently).
>
> TLS 2.0-called-1.3 seems to be doing the same thing that HTTPS 2 did,
> targeting the specialised requirements of web servers/browsers and ignoring
> everything else.  The HTTPS 2 WG's response to this at the time was "let them
> eat HTTP 1.1", so that you've now got HTTP-for-Google (2.0) and HTTP-for-
> everything-else (1.1).  Is the TLS equivalent going to be "let them eat TLS
> 1.1"?

What features in TLS 1.3, other than 0-RTT (which is optional!) make
it unsuitable for embedded devices?
>
> (General note: That one short post has generated an enormous amount of email
>  off-list as well as on, for all those waiting for replies to private mail,
>  please be patient, I'm working through it...).
>
> Peter.
>
> [0] This all feels somewhat biblical, "you are 2.0 son of 1.2, but you will be
> known as 1.3".
> _