Re: [TLS] Controlling use of SHA-1

[Russ Housley]

 
I am also in favor of this change: it prohibits the server to send SHA-1 certs 
when signature_algorithms does not include SHA-1.

Russ

On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson  
wrote:
The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is acceptable.

That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.

I've opened PR #317 for this, but the commit is probably more useful
to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):

https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

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

Re: [TLS] Controlling use of SHA-1

[Rob Stradling]

On 22/10/15 00:52, Dave Garrett wrote:

I'm in favor of this change as well. It annoys Viktor, as it changes the 
fallback in a way that isn't ideal for some cases that trust the cert directly 
or with OE,


IINM this also changes the fallback for servers that choose to include a 
PKIX trust anchor certificate in the Server Certificate message.


Lots of publicly trusted root certificates have sha1WithRSAEncryption 
signatures.  TLS clients typically don't verify these SHA-1 signatures, 
so there's no rush to remove them from trust anchor stores.



but I think it's better than the alternative.


Why would it make sense to prohibit the sending of PKIX trust anchor 
certificates that have sha1WithRSAEncryption signatures?



Dave


On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote:

I think this is the right answer and parallels what we are doing with PSS.

-Ekr


On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson 
wrote:


The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is acceptable.

That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.

I've opened PR #317 for this, but the commit is probably more useful
to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):


https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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

Re: [TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Roland Zink]

Am 21.10.2015 um 20:22 schrieb Hanno Böck:

Not sure if I'm getting anything wrong, but doesn't this open a huge
security hole?

Yes I think so. Mitm may redirect you.


Scenario right now is that if I want to be secure on a webpage I type
in its HTTPS URL (either directly or through a bookmark) and can be
pretty much sure that as long as I don't click on external links that
I'll stay on that webpage.
No the server may redirect you and even worse the parts may be retrieved 
from dozens of places and you have no clue from where. Common practice 
is that your privacy is sold to third parties through ads, analytics, 
like or pin buttons. This is not what I would expect from a secure site.

Basically this proposal would allow a man-in-the-middle to send
me to another webpage each time I click on a (supposedly https
protected) link. Given that there are many browsers these days
(mobile) that hide the URL bar thats even more severe.

This severely changes the security expectations one can have from a
browser.

Regards,
Roland



___
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] Allow NamedGroups from the server?

[Martin Rex]

Eric Rescorla wrote:
> Dave Garrett  wrote:
> 
>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
>>> https://github.com/tlswg/tls13-spec/issues/292
>>>
>>> Presently, RFC 4492 only specifies the EC points it can support in
>>> ServerHello, but does not let the server indicate which EC curves it
>>> supports. Unless I'm missing something, this means that there's
>>> no way for the server to indicate what groups it would support.
>>>
>>> That seems less than ideal. There seem like three options here:
>>>
>>> 1. Put it in CertificateRequest
>>> 2. Send it in ServerHello
>>> 3. Do nothing.
>>
>> I prefer #2. I don't think encryption is necessarily required for this,
>> but EncryptedExtensions is fine too (Martin's 2b).
>>
>> I'm generally against putting it in CertificateRequest, as we're reusing
>> an existing hello extension so keeping it in a hello message (or it's
>> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
>> though)
> 
> 
> This would need to be limited to 1.3 in any case because in all the other
> cases it would be illegal.


Why do you believe that it would be "illegal" for a TLSv1.[012] server
to return a "Supported Elliptic Curves" TLS extension in ServerHello
in response to the presence of such a TLS extension in ClientHello?

rfc4492 does not define semantics for the presence of "Supported Elliptic
Curves" TLS extension in ServerHello, but on a quick read, it also does
not prohibit including/sending it.

https://tools.ietf.org/html/rfc4492#section-5.2


-Martin

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

Re: [TLS] Allow NamedGroups from the server?

[Eric Rescorla]

On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex  wrote:

> Eric Rescorla wrote:
> > Dave Garrett  wrote:
> >
> >> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> >>> https://github.com/tlswg/tls13-spec/issues/292
> >>>
> >>> Presently, RFC 4492 only specifies the EC points it can support in
> >>> ServerHello, but does not let the server indicate which EC curves it
> >>> supports. Unless I'm missing something, this means that there's
> >>> no way for the server to indicate what groups it would support.
> >>>
> >>> That seems less than ideal. There seem like three options here:
> >>>
> >>> 1. Put it in CertificateRequest
> >>> 2. Send it in ServerHello
> >>> 3. Do nothing.
> >>
> >> I prefer #2. I don't think encryption is necessarily required for this,
> >> but EncryptedExtensions is fine too (Martin's 2b).
> >>
> >> I'm generally against putting it in CertificateRequest, as we're reusing
> >> an existing hello extension so keeping it in a hello message (or it's
> >> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
> >> though)
> >
> >
> > This would need to be limited to 1.3 in any case because in all the other
> > cases it would be illegal.
>
>
> Why do you believe that it would be "illegal" for a TLSv1.[012] server
> to return a "Supported Elliptic Curves" TLS extension in ServerHello
> in response to the presence of such a TLS extension in ClientHello?
>
> rfc4492 does not define semantics for the presence of "Supported Elliptic
> Curves" TLS extension in ServerHello, but on a quick read, it also does
> not prohibit including/sending it.
>
> https://tools.ietf.org/html/rfc4492#section-5.2


Well, the draft says that it is defining two ClientHello extensions
(supported elliptic curves and supported point formats) and that it is
defining
one ServerHello extension, so if the server is sending supported elliptic
curves it's doing something undefined. I don't think you need to have
an explicit prohibition to suggest that doing something undefined isn't
great.

>From an implementation perspective, I wouldn't be surprised if client
implementations choked on the server sending this. I had to check
to see if NSS would do so. It doesn't, but given the way the code
is written, it wouldn't have surprised me if it checked that all extensions
were handled and choked otherwise.

-Ekr


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

Re: [TLS] Version in record MAC

[Eric Rescorla]

I'm mostly convinced by this text in RFC 5116:
http://tools.ietf.org/html/rfc5116#section-2.1

   Because the authenticated decryption process
   detects incorrect nonce values, no security failure will result if a
   nonce is incorrectly reconstructed and fed into an authenticated
   decryption operation.  Any nonce reconstruction method will need to
   take into account the possibility of loss or reorder of ciphertexts
  between the encryption and decryption processes.

It would probably be worth checking with the cryptographers in the room.

CCing Hugo and McGrew.

-Ekr




On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley 
wrote:

> On Monday, October 19, 2015, Martin Thomson 
> wrote:
>
>> On 19 October 2015 at 11:17, Eric Rescorla  wrote:
>> > Yeah, I think that's riding the nonce far too hard.
>>
>> On what basis?  Any change in the nonce will cause the record
>> decryption to fail.  That's the property we're looking for here, isn't
>> it?
>
>
> I don't believe that there's any reason to include the sequence number in
> the AD input of an AEAD. I think that an empty AD for TLS would be fine now
> that the content type is encrypted. (Not that I deeply care either way.)
>
>
> Cheers
>
> AGL
>
>
> --
> Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Version in record MAC

[David McGrew (mcgrew)]

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Thursday, October 22, 2015 9:33 AM
To: Adam Langley
Cc: Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew)
Subject: Re: [TLS] Version in record MAC

I'm mostly convinced by this text in RFC 5116:
http://tools.ietf.org/html/rfc5116#section-2.1


   Because the authenticated decryption process

   detects incorrect nonce values, no security failure will result if a

   nonce is incorrectly reconstructed and fed into an authenticated

   decryption operation.  Any nonce reconstruction method will need to

   take into account the possibility of loss or reorder of ciphertexts

   between the encryption and decryption processes.

It would probably be worth checking with the cryptographers in the room.

CCing Hugo and McGrew.

-Ekr





On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley 
mailto:a...@imperialviolet.org>> wrote:
On Monday, October 19, 2015, Martin Thomson 
mailto:martin.thom...@gmail.com>> wrote:
On 19 October 2015 at 11:17, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
> Yeah, I think that's riding the nonce far too hard.

On what basis?  Any change in the nonce will cause the record
decryption to fail.  That's the property we're looking for here, isn't
it?

I don't believe that there's any reason to include the sequence number in the 
AD input of an AEAD. I think that an empty AD for TLS would be fine now that 
the content type is encrypted. (Not that I deeply care either way.)

Agreed.  Any value that always goes into the nonce doesn’t need to go into the 
AD.

David


Cheers

AGL


--
Adam Langley a...@imperialviolet.org 
https://www.imperialviolet.org

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

Re: [TLS] Version in record MAC

[Eric Rescorla]

Thanks for the quick response, David. I now agree with Martin and
Adam that we should remove this.

Chairs, I haven't seen any objections any reason I shouldn't make this
change?

-Ekr


On Thu, Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew) 
wrote:

>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
> *Sent:* Thursday, October 22, 2015 9:33 AM
> *To:* Adam Langley
> *Cc:* Martin Thomson; tls@ietf.org; Hugo Krawczyk; David McGrew (mcgrew)
> *Subject:* Re: [TLS] Version in record MAC
>
>
>
> I'm mostly convinced by this text in RFC 5116:
>
> http://tools.ietf.org/html/rfc5116#section-2.1
>
>
>
>Because the authenticated decryption process
>
>detects incorrect nonce values, no security failure will result if a
>
>nonce is incorrectly reconstructed and fed into an authenticated
>
>decryption operation.  Any nonce reconstruction method will need to
>
>take into account the possibility of loss or reorder of ciphertexts
>
>between the encryption and decryption processes.
>
> It would probably be worth checking with the cryptographers in the room.
>
> CCing Hugo and McGrew.
>
> -Ekr
>
>
>
>
>
>
>
> On Mon, Oct 19, 2015 at 5:46 PM, Adam Langley 
> wrote:
>
> On Monday, October 19, 2015, Martin Thomson 
> wrote:
>
> On 19 October 2015 at 11:17, Eric Rescorla  wrote:
> > Yeah, I think that's riding the nonce far too hard.
>
> On what basis?  Any change in the nonce will cause the record
> decryption to fail.  That's the property we're looking for here, isn't
> it?
>
>
>
> I don't believe that there's any reason to include the sequence number in
> the AD input of an AEAD. I think that an empty AD for TLS would be fine now
> that the content type is encrypted. (Not that I deeply care either way.)
>
>
>
> Agreed.  Any value that always goes into the nonce doesn’t need to go into
> the AD.
>
>
>
> David
>
>
>
>
>
> Cheers
>
>
>
> AGL
>
>
>
> --
> Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

[Viktor Dukhovni]

On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote:

> IINM this also changes the fallback for servers that choose to include a
> PKIX trust anchor certificate in the Server Certificate message.

The signatures of trust-anchor (i.e. self-signed) certificates MUST
NOT be constrained by this proposal, even if the WG otherwise
chooses to step outside the proper scope of TLS into PKIX chain
validation.

Please note that the self-signature of the CAcert.org 4096-bit root
CA is MD5.

> Why would it make sense to prohibit the sending of PKIX trust anchor
> certificates that have sha1WithRSAEncryption signatures?

It makes no sense to restrict the signatures of trust-anchors.  It
makes little sense to restrict the signatures certificates servers
can send to clients to be evaluated per the client's policy.

-- 
Viktor.

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

Re: [TLS] Controlling use of SHA-1

[Geoffrey Keating]

Viktor Dukhovni  writes:

> On Thu, Oct 22, 2015 at 08:42:51AM +0100, Rob Stradling wrote:
> 
> > IINM this also changes the fallback for servers that choose to include a
> > PKIX trust anchor certificate in the Server Certificate message.
> 
> The signatures of trust-anchor (i.e. self-signed) certificates MUST
> NOT be constrained by this proposal, even if the WG otherwise
> chooses to step outside the proper scope of TLS into PKIX chain
> validation.

I believe nothing is constrained by this proposal in the form you're
thinking.  That is, it's only if you have two versions of the root,
one with a requested algorithm and one without, that this proposal
comes into play.

At least, I think that's the intent.  It might help to clarify this in
the proposal.  It should be noted that the situation can become quite
complicated, for example it's possible that there might be one chain
which uses only SHA-2 which chains to one newer root, and another
chain which uses mostly SHA-1 and chains to a different older root.

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

Re: [TLS] Controlling use of SHA-1

[Benjamin Kaduk]

On 10/22/2015 09:24 AM, Viktor Dukhovni wrote:
>
>> Why would it make sense to prohibit the sending of PKIX trust anchor
>> certificates that have sha1WithRSAEncryption signatures?
> It makes no sense to restrict the signatures of trust-anchors.  It
> makes little sense to restrict the signatures certificates servers
> can send to clients to be evaluated per the client's policy.
>

% a certificate that specifies a trust anchor MAY be omitted from the chain

The client cannot decide that the signature on the root cert the server
sent is bad, if the server does not send the root cert.

-Ben

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

Re: [TLS] Allow NamedGroups from the server?

[Andrei Popov]

Would the server-side “supported elliptic curves” be used for anything other 
than guiding client cert selection?

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Thursday, October 22, 2015 6:29 AM
To: m...@sap.com
Cc: tls@ietf.org
Subject: Re: [TLS] Allow NamedGroups from the server?



On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex mailto:m...@sap.com>> 
wrote:
Eric Rescorla wrote:
> Dave Garrett mailto:davemgarr...@gmail.com>> wrote:
>
>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
>>> https://github.com/tlswg/tls13-spec/issues/292
>>>
>>> Presently, RFC 4492 only specifies the EC points it can support in
>>> ServerHello, but does not let the server indicate which EC curves it
>>> supports. Unless I'm missing something, this means that there's
>>> no way for the server to indicate what groups it would support.
>>>
>>> That seems less than ideal. There seem like three options here:
>>>
>>> 1. Put it in CertificateRequest
>>> 2. Send it in ServerHello
>>> 3. Do nothing.
>>
>> I prefer #2. I don't think encryption is necessarily required for this,
>> but EncryptedExtensions is fine too (Martin's 2b).
>>
>> I'm generally against putting it in CertificateRequest, as we're reusing
>> an existing hello extension so keeping it in a hello message (or it's
>> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
>> though)
>
>
> This would need to be limited to 1.3 in any case because in all the other
> cases it would be illegal.


Why do you believe that it would be "illegal" for a TLSv1.[012] server
to return a "Supported Elliptic Curves" TLS extension in ServerHello
in response to the presence of such a TLS extension in ClientHello?

rfc4492 does not define semantics for the presence of "Supported Elliptic
Curves" TLS extension in ServerHello, but on a quick read, it also does
not prohibit including/sending it.

https://tools.ietf.org/html/rfc4492#section-5.2

Well, the draft says that it is defining two ClientHello extensions
(supported elliptic curves and supported point formats) and that it is defining
one ServerHello extension, so if the server is sending supported elliptic
curves it's doing something undefined. I don't think you need to have
an explicit prohibition to suggest that doing something undefined isn't
great.

From an implementation perspective, I wouldn't be surprised if client
implementations choked on the server sending this. I had to check
to see if NSS would do so. It doesn't, but given the way the code
is written, it wouldn't have surprised me if it checked that all extensions
were handled and choked otherwise.

-Ekr


-Martin

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

Re: [TLS] Allow NamedGroups from the server?

[Eric Rescorla]

Not that I am aware of.

On Thu, Oct 22, 2015 at 10:06 AM, Andrei Popov 
wrote:

> Would the server-side “supported elliptic curves” be used for anything
> other than guiding client cert selection?
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 22, 2015 6:29 AM
> *To:* m...@sap.com
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Allow NamedGroups from the server?
>
>
>
>
>
>
>
> On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex  wrote:
>
> Eric Rescorla wrote:
> > Dave Garrett  wrote:
> >
> >> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> >>> https://github.com/tlswg/tls13-spec/issues/292
> 
> >>>
> >>> Presently, RFC 4492 only specifies the EC points it can support in
> >>> ServerHello, but does not let the server indicate which EC curves it
> >>> supports. Unless I'm missing something, this means that there's
> >>> no way for the server to indicate what groups it would support.
> >>>
> >>> That seems less than ideal. There seem like three options here:
> >>>
> >>> 1. Put it in CertificateRequest
> >>> 2. Send it in ServerHello
> >>> 3. Do nothing.
> >>
> >> I prefer #2. I don't think encryption is necessarily required for this,
> >> but EncryptedExtensions is fine too (Martin's 2b).
> >>
> >> I'm generally against putting it in CertificateRequest, as we're reusing
> >> an existing hello extension so keeping it in a hello message (or it's
> >> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
> >> though)
> >
> >
> > This would need to be limited to 1.3 in any case because in all the other
> > cases it would be illegal.
>
>
> Why do you believe that it would be "illegal" for a TLSv1.[012] server
> to return a "Supported Elliptic Curves" TLS extension in ServerHello
> in response to the presence of such a TLS extension in ClientHello?
>
> rfc4492 does not define semantics for the presence of "Supported Elliptic
> Curves" TLS extension in ServerHello, but on a quick read, it also does
> not prohibit including/sending it.
>
> https://tools.ietf.org/html/rfc4492#section-5.2
> 
>
>
>
> Well, the draft says that it is defining two ClientHello extensions
>
> (supported elliptic curves and supported point formats) and that it is
> defining
>
> one ServerHello extension, so if the server is sending supported elliptic
>
> curves it's doing something undefined. I don't think you need to have
>
> an explicit prohibition to suggest that doing something undefined isn't
>
> great.
>
>
>
> From an implementation perspective, I wouldn't be surprised if client
>
> implementations choked on the server sending this. I had to check
>
> to see if NSS would do so. It doesn't, but given the way the code
>
> is written, it wouldn't have surprised me if it checked that all extensions
>
> were handled and choked otherwise.
>
>
>
> -Ekr
>
>
>
>
>
> -Martin
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Allow NamedGroups from the server?

[Andrei Popov]

Then my argument would be: why send extra bytes in each ServerHello when TLS 
client auth is not used most of the time? In this case, CertificateRequest 
seems to be a better place.

From: Eric Rescorla [mailto:e...@rtfm.com]
Sent: Thursday, October 22, 2015 10:08 AM
To: Andrei Popov 
Cc: m...@sap.com; tls@ietf.org
Subject: Re: [TLS] Allow NamedGroups from the server?

Not that I am aware of.

On Thu, Oct 22, 2015 at 10:06 AM, Andrei Popov 
mailto:andrei.po...@microsoft.com>> wrote:
Would the server-side “supported elliptic curves” be used for anything other 
than guiding client cert selection?

Cheers,

Andrei

From: TLS [mailto:tls-boun...@ietf.org] On Behalf 
Of Eric Rescorla
Sent: Thursday, October 22, 2015 6:29 AM
To: m...@sap.com
Cc: tls@ietf.org
Subject: Re: [TLS] Allow NamedGroups from the server?



On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex mailto:m...@sap.com>> 
wrote:
Eric Rescorla wrote:
> Dave Garrett mailto:davemgarr...@gmail.com>> wrote:
>
>> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
>>> https://github.com/tlswg/tls13-spec/issues/292
>>>
>>> Presently, RFC 4492 only specifies the EC points it can support in
>>> ServerHello, but does not let the server indicate which EC curves it
>>> supports. Unless I'm missing something, this means that there's
>>> no way for the server to indicate what groups it would support.
>>>
>>> That seems less than ideal. There seem like three options here:
>>>
>>> 1. Put it in CertificateRequest
>>> 2. Send it in ServerHello
>>> 3. Do nothing.
>>
>> I prefer #2. I don't think encryption is necessarily required for this,
>> but EncryptedExtensions is fine too (Martin's 2b).
>>
>> I'm generally against putting it in CertificateRequest, as we're reusing
>> an existing hello extension so keeping it in a hello message (or it's
>> trailing encrypted field) seems best. (restricted to TLS 1.3+ clients,
>> though)
>
>
> This would need to be limited to 1.3 in any case because in all the other
> cases it would be illegal.


Why do you believe that it would be "illegal" for a TLSv1.[012] server
to return a "Supported Elliptic Curves" TLS extension in ServerHello
in response to the presence of such a TLS extension in ClientHello?

rfc4492 does not define semantics for the presence of "Supported Elliptic
Curves" TLS extension in ServerHello, but on a quick read, it also does
not prohibit including/sending it.

https://tools.ietf.org/html/rfc4492#section-5.2

Well, the draft says that it is defining two ClientHello extensions
(supported elliptic curves and supported point formats) and that it is defining
one ServerHello extension, so if the server is sending supported elliptic
curves it's doing something undefined. I don't think you need to have
an explicit prohibition to suggest that doing something undefined isn't
great.

From an implementation perspective, I wouldn't be surprised if client
implementations choked on the server sending this. I had to check
to see if NSS would do so. It doesn't, but given the way the code
is written, it wouldn't have surprised me if it checked that all extensions
were handled and choked otherwise.

-Ekr


-Martin


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

Re: [TLS] Proposal for client auth

[Ilari Liusvaara]

On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> Folks,
> 
> At the Seattle interim, we decided to have a small ad hoc design team
> go and figure out how to harmonize the various forms of client
> authentication. I've posted a WIP version of the output of that work
> at:
> 
> https://github.com/tlswg/tls13-spec/pull/316
> 
> 
> So, what this draft does is adopt the following three messages.
> 
>Certificate
>CertificateVerify
>Finished
> 
> As the "TLS Authentication Block" and send them whenever we want to do
> authentication. [Note that we may eventually merge messages here, but
> that doesn't affect the logic.]
> 
> In every case, the input to the block would be:
> 
>- A session context (SC) which is (generally) the handshake
>  transcript up to this point.
>- A base key to compute the finished key from (the finished
>  keys are directional, so the client and server keys are
>  different).
> 
> And then the signature covers: SC + Certificate
> And the MAC covers SC + Certificate + CertificateVerify

Perhaps I'm reading things wrong, but this change seems to pass
raw Context+Certificate+Signature to HMAC to compute Finished.
Due to the way HMAC works, this requires to know the key for
the MAC before one can start the pipe (I didn't look when it
becomes available) and requires a separate pipe from ordinary
transcript hash.

Previously, Finished messages used the same transcript hash
pipe as everything else using transcript hashing.


-Ilari

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

Re: [TLS] Controlling use of SHA-1

[Martin Thomson]

On 22 October 2015 at 09:19, Benjamin Kaduk  wrote:
>
> % a certificate that specifies a trust anchor MAY be omitted from the chain
>
> The client cannot decide that the signature on the root cert the server
> sent is bad, if the server does not send the root cert.

Yes, that was my thinking.

I expect that if a certificate is sent, then it might have to be
checked.  As opposed to the roots, which are rarely sent or checked.

Maybe it would help if Victor could describe the situation in which he
thinks that it would be appropriate to send a certificate that is
signed by MD5.

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

Re: [TLS] Proposal for client auth

[Eric Rescorla]

On Thu, Oct 22, 2015 at 10:26 AM, Ilari Liusvaara 
wrote:

> On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > At the Seattle interim, we decided to have a small ad hoc design team
> > go and figure out how to harmonize the various forms of client
> > authentication. I've posted a WIP version of the output of that work
> > at:
> >
> > https://github.com/tlswg/tls13-spec/pull/316
> >
> >
> > So, what this draft does is adopt the following three messages.
> >
> >Certificate
> >CertificateVerify
> >Finished
> >
> > As the "TLS Authentication Block" and send them whenever we want to do
> > authentication. [Note that we may eventually merge messages here, but
> > that doesn't affect the logic.]
> >
> > In every case, the input to the block would be:
> >
> >- A session context (SC) which is (generally) the handshake
> >  transcript up to this point.
> >- A base key to compute the finished key from (the finished
> >  keys are directional, so the client and server keys are
> >  different).
> >
> > And then the signature covers: SC + Certificate
> > And the MAC covers SC + Certificate + CertificateVerify
>
> Perhaps I'm reading things wrong, but this change seems to pass
> raw Context+Certificate+Signature to HMAC to compute Finished.
> Due to the way HMAC works, this requires to know the key for
> the MAC before one can start the pipe (I didn't look when it
> becomes available) and requires a separate pipe from ordinary
> transcript hash.
>
> Previously, Finished messages used the same transcript hash
> pipe as everything else using transcript hashing.


I just messed up the editing.

It's the same plan as before. HMAC(key, handshake_hash). So, for
example, the signature from the server would cover all messages
between ClientHello and Certificate (inclusive) and the MAC would
cover all messages from ClientHello and CertificateVerify inclusive.

I'll fix this in the text.

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

Re: [TLS] Allow NamedGroups from the server?

[Martin Thomson]

On 22 October 2015 at 10:11, Andrei Popov  wrote:
> Then my argument would be: why send extra bytes in each ServerHello when TLS
> client auth is not used most of the time? In this case, CertificateRequest
> seems to be a better place.

I think that this is the best argument for CertificateRequest.

We can prohibit the inclusion of the extension in ServerHello (or
Server EncryptedExtensions) as we please then.  I would argue for
prohibiting it, since it has no purpose.

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

Re: [TLS] Allow NamedGroups from the server?

[Martin Rex]

Andrei Popov wrote:
>
> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,
> CertificateRequest seems to be a better place.

I'm perfectly OK with the server _not_ sending/including a TLS extension
"Supported Elliptic Curves" in ServerHello if the server is not going
to request a client certificate.

This is first of all about a fully backwards-compatible change of the
protocol, which does not need to be seperately negotiated, and which
is optional to use (for the server).

By including the information in "CertificateRequest", it will be
necessary to change the CertificateRequest PDU, and that will require
a new negotiation of such a changed PDU for existing TLS protocol
versions (TLSv1.0/1.1/1.2).

Conveying the information through ServerHello should work just fine
with existing implementations, does not need any additional negotiation
through ClientHello&ServerHello and does not need to change an existing
PDU (CertificateRequest).


-Martin

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

Re: [TLS] Allow NamedGroups from the server?

[Eric Rescorla]

On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex  wrote:

> Andrei Popov wrote:
> >
> > Then my argument would be: why send extra bytes in each ServerHello
> > when TLS client auth is not used most of the time? In this case,
> > CertificateRequest seems to be a better place.
>
> I'm perfectly OK with the server _not_ sending/including a TLS extension
> "Supported Elliptic Curves" in ServerHello if the server is not going
> to request a client certificate.
>
> This is first of all about a fully backwards-compatible change of the
> protocol, which does not need to be seperately negotiated, and which
> is optional to use (for the server).
>

It's not clear that it's in fact backwards compatible, since this is an
undefined
area in the spec.

As I mentioned earlier, I wasn't sure how NSS behaved here and so before
we even considered this [and I would still have to test to be totally sure]
and we would need to take some sort of measurement
from servers to determine that this does not cause bustage.


By including the information in "CertificateRequest", it will be
> necessary to change the CertificateRequest PDU, and that will require
> a new negotiation of such a changed PDU for existing TLS protocol
> versions (TLSv1.0/1.1/1.2).
>

We are already changing CertificateRequest in TLS 1.3 and we could (and
probably should do nothing for previous versions of TLS).

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

Re: [TLS] Controlling use of SHA-1

[Salz, Rich]

> Maybe it would help if Victor could describe the situation in which he thinks
> that it would be appropriate to send a certificate that is signed by MD5.

Or where an application upgrades to a new library and expects EVERYTHING to 
work exactly as it used to, with no changes.

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

Re: [TLS] Controlling use of SHA-1

[Benjamin Kaduk]

On 10/22/2015 12:45 PM, Salz, Rich wrote:
>> Maybe it would help if Victor could describe the situation in which he thinks
>> that it would be appropriate to send a certificate that is signed by MD5.
> Or where an application upgrades to a new library and expects EVERYTHING to 
> work exactly as it used to, with no changes.
>

That one's actually not very hard -- in a system like FreeBSD ports or
NetBSD pkgsrc, the application and the library are separately maintained
within the whole tree, and when someone builds the application, they get
whatever version of the library happens to be in the tree at that time. 
The library can easily get upgraded without the application maintainer
noticing, and the automated systems are only likely to detect
compilation failure, not runtime behavior changes.

That is, the library update can be transparent to the end-user, who will
continue to expect normal functionality and expect everything to work.

-Ben

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

Re: [TLS] Controlling use of SHA-1

[Salz, Rich]

> That is, the library update can be transparent to the end-user, who will
> continue to expect normal functionality and expect everything to work.

Should all applications suddenly start using TLS 1.3 without any changes?  
Really?  Or should what *they used to do* just work as it was?  If that?  
Suppose what they used to do is now considered bad practice?

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

Re: [TLS] Allow NamedGroups from the server?

[Andrei Popov]

To be clear, I'm in favor of introducing server-side NamedGroups in 1.3. I've 
no interest in making this change in any earlier protocol versions.

Cheers,

Andrei

From: Eric Rescorla
Sent: 10/22/2015 10:40 AM
To: m...@sap.com
Cc: Andrei Popov; tls@ietf.org
Subject: Re: [TLS] Allow NamedGroups from the server?



On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex 
mailto:m...@sap.com>> wrote:
Andrei Popov wrote:
>
> Then my argument would be: why send extra bytes in each ServerHello
> when TLS client auth is not used most of the time? In this case,
> CertificateRequest seems to be a better place.

I'm perfectly OK with the server _not_ sending/including a TLS extension
"Supported Elliptic Curves" in ServerHello if the server is not going
to request a client certificate.

This is first of all about a fully backwards-compatible change of the
protocol, which does not need to be seperately negotiated, and which
is optional to use (for the server).

It's not clear that it's in fact backwards compatible, since this is an 
undefined
area in the spec.

As I mentioned earlier, I wasn't sure how NSS behaved here and so before
we even considered this [and I would still have to test to be totally sure]
and we would need to take some sort of measurement
from servers to determine that this does not cause bustage.


By including the information in "CertificateRequest", it will be
necessary to change the CertificateRequest PDU, and that will require
a new negotiation of such a changed PDU for existing TLS protocol
versions (TLSv1.0/1.1/1.2).

We are already changing CertificateRequest in TLS 1.3 and we could (and
probably should do nothing for previous versions of TLS).

-Ekr

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

Re: [TLS] Controlling use of SHA-1

[Viktor Dukhovni]

On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin Thomson wrote:

> > % a certificate that specifies a trust anchor MAY be omitted from the chain
> >
> > The client cannot decide that the signature on the root cert the server
> > sent is bad, if the server does not send the root cert.
> 
> Yes, that was my thinking.
> 
> I expect that if a certificate is sent, then it might have to be
> checked.  As opposed to the roots, which are rarely sent or checked.

The roots are sent more frequently than you imagine.  With DANE-TA(2)
they MUST be sent if the server's TLSA record nominates a self-signed
trust-anchor.  Further-more, OpenSSL sends whatever the administrator
puts in the server "chain file", it would be wrong for it to
selectively delete the configured certificates, and many systems
include the root CA in the chain file.

> Maybe it would help if Victor could describe the situation in which he
> thinks that it would be appropriate to send a certificate that is
> signed by MD5.

The CAcert.org root is self-signed with MD5 and is sent as part of
the chain by various systems.  This self-signature is harmless,
but some systems pedantically disrupt the handshake in response.

For example, some Postfix clients are configured with CAcert.org
client cert chains, and provide client certs to the
mail.protection.outlook.com MTAs which then force a downgrade to
cleartext by refusing to continue the handshake.

The refusal to accept an MD5 self-signature is pedantic security
degradation.

-- 
Viktor.

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

Re: [TLS] Controlling use of SHA-1

[Watson Ladd]

On Oct 22, 2015 2:00 PM, "Salz, Rich"  wrote:
>
> > That is, the library update can be transparent to the end-user, who will
> > continue to expect normal functionality and expect everything to work.
>
> Should all applications suddenly start using TLS 1.3 without any
changes?  Really?  Or should what *they used to do* just work as it was?
If that?  Suppose what they used to do is now considered bad practice?

Ideally, yes. Applications never cared about what was happening, but wanted
a "secure this channel" magic call.

It's particularly important when we want to hunt down and eliminate bugs.
>
> ___
> 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] Controlling use of SHA-1

[Andrei Popov]

What if we just made an explicit exception for root cert hash algorithms and 
not constrained them by the client's alg list?

From: Viktor Dukhovni
Sent: 10/22/2015 11:12 AM
To: tls@ietf.org
Subject: Re: [TLS] Controlling use of SHA-1

On Thu, Oct 22, 2015 at 10:30:33AM -0700, Martin Thomson wrote:

> > % a certificate that specifies a trust anchor MAY be omitted from the chain
> >
> > The client cannot decide that the signature on the root cert the server
> > sent is bad, if the server does not send the root cert.
>
> Yes, that was my thinking.
>
> I expect that if a certificate is sent, then it might have to be
> checked.  As opposed to the roots, which are rarely sent or checked.

The roots are sent more frequently than you imagine.  With DANE-TA(2)
they MUST be sent if the server's TLSA record nominates a self-signed
trust-anchor.  Further-more, OpenSSL sends whatever the administrator
puts in the server "chain file", it would be wrong for it to
selectively delete the configured certificates, and many systems
include the root CA in the chain file.

> Maybe it would help if Victor could describe the situation in which he
> thinks that it would be appropriate to send a certificate that is
> signed by MD5.

The 
https://na01.safelinks.protection.outlook.com/?url=CAcert.org&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0kTNAt0ca9TAbtb1Gt5LanTfYajUCeKkuFZp59a9ljs%3d
 root is self-signed with MD5 and is sent as part of
the chain by various systems.  This self-signature is harmless,
but some systems pedantically disrupt the handshake in response.

For example, some Postfix clients are configured with 
https://na01.safelinks.protection.outlook.com/?url=CAcert.org&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0kTNAt0ca9TAbtb1Gt5LanTfYajUCeKkuFZp59a9ljs%3d
client cert chains, and provide client certs to the
https://na01.safelinks.protection.outlook.com/?url=mail.protection.outlook.com&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fKDA5Lyxn7S8P4BVFDD1mL1oyIzGYif5X2j4dH0NG80%3d
 MTAs which then force a downgrade to
cleartext by refusing to continue the handshake.

The refusal to accept an MD5 self-signature is pedantic security
degradation.

--
Viktor.

___
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OYsiJgPkphzBreBA9Uv0aKCyw2yMEaa2QGNInB41x%2bc%3d
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

[Benjamin Kaduk]

On 10/22/2015 01:00 PM, Salz, Rich wrote:
>> That is, the library update can be transparent to the end-user, who will
>> continue to expect normal functionality and expect everything to work.
> Should all applications suddenly start using TLS 1.3 without any changes?  
> Really?  Or should what *they used to do* just work as it was?  If that?  
> Suppose what they used to do is now considered bad practice?

If we (okay, not "we", library implementors) require explicit
application opt-in to TLS 1.3, the adoption rate is probably not going
to be very good.  So, yes, I think applications should start using TLS
1.3 without any changes.

-Ben

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

Re: [TLS] Controlling use of SHA-1

[Salz, Rich]

> If we (okay, not "we", library implementors) require explicit application opt-
> in to TLS 1.3, the adoption rate is probably not going to be very good.  So, 
> yes,
> I think applications should start using TLS 1.3 without any changes.

And what about 0RTT?  Removed support for some crypto?  Various other semantic 
changes?

What you're really saying is "just like it always used to be, just better."

And I want a pony.

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

Re: [TLS] Controlling use of SHA-1

[Watson Ladd]

On Oct 22, 2015 2:20 PM, "Salz, Rich"  wrote:
>
> > If we (okay, not "we", library implementors) require explicit
application opt-
> > in to TLS 1.3, the adoption rate is probably not going to be very
good.  So, yes,
> > I think applications should start using TLS 1.3 without any changes.
>
> And what about 0RTT?  Removed support for some crypto?  Various other
semantic changes?

If you don't enable 0RTT support and ignore removed crypto, what breaks?
Most apps don't use renegotiation anyway?
>
> What you're really saying is "just like it always used to be, just
better."
>
> And I want a pony.

Most applications want a simple API that hides all the complexities of TLS.
If OpenSSL had done that, then it would be easy to see how enabling 1.2
won't cause problems for those apps which said "you take care of it".
>
> ___
> 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] Controlling use of SHA-1

[Ilari Liusvaara]

On Thu, Oct 22, 2015 at 01:18:37PM -0500, Benjamin Kaduk wrote:
> On 10/22/2015 01:00 PM, Salz, Rich wrote:
> >> That is, the library update can be transparent to the end-user, who will
> >> continue to expect normal functionality and expect everything to work.
> > Should all applications suddenly start using TLS 1.3 without any changes?
> >  Really?  Or should what *they used to do* just work as it was?  If that?
> > Suppose what they used to do is now considered bad practice?
> 
> If we (okay, not "we", library implementors) require explicit
> application opt-in to TLS 1.3, the adoption rate is probably not going
> to be very good.  So, yes, I think applications should start using TLS
> 1.3 without any changes.

As a note, I have personally seen bad security resulting from
application having to enable TLS versions.

I expect applications to start supporting TLS 1.3 with just upgrading
the crypto shared object, without even changing the application
executable.

Of course, features like 0-RTT won't work without application support,
but nothing existing uses those anyway.


-Ilari

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

Re: [TLS] Controlling use of SHA-1

[Salz, Rich]

> Most applications want a simple API that hides all the complexities of TLS. 
> If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't 
> cause problems for those apps which said "you take care of it".

As someone with a long history of building, influencing, and using libraries 
and their API's, this is not easy.

Would you disable 0RTT because the earlydata might be replayed?  That would be 
the secure thing to do, so you make applications that want to use new features 
do extra work, ok. Would you disable AES-GCM because it's new, and perhaps it's 
an ARM-based application so the CPU cost is expensive? That's the insecure 
thing to do, isn't it?  Who makes that trade-off? SCSV?  SSLv2? Trust anchors?

I still want a pony.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

[Eric Rescorla]

On Thu, Oct 22, 2015 at 11:00 AM, Salz, Rich  wrote:

> > That is, the library update can be transparent to the end-user, who will
> > continue to expect normal functionality and expect everything to work.
>
> Should all applications suddenly start using TLS 1.3 without any changes?
> Really?  Or should what *they used to do* just work as it was?  If that?
> Suppose what they used to do is now considered bad practice?


I would say anything they do that's good practice should keep working :)

-Ekr


> ___
> 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] Controlling use of SHA-1

[Eric Rescorla]

On Thu, Oct 22, 2015 at 11:20 AM, Salz, Rich  wrote:

> > If we (okay, not "we", library implementors) require explicit
> application opt-
> > in to TLS 1.3, the adoption rate is probably not going to be very good.
> So, yes,
> > I think applications should start using TLS 1.3 without any changes.
>
> And what about 0RTT?  Removed support for some crypto?  Various other
> semantic changes?
>

So, I think we've agreed that using 0-RTT should require explicit action.
And similarly if you have required some crypto algorithm that TLS 1.3
doesn't support (or you don't support any of the new ones) it should
fail. However, if you are using a conceptually compatible subset of
TLS 1.2 (i.e., modern algorithms, no renegotiation),
then I would expect you to be able to drop in TLS 1.3 and have
it work.

-Ekr



What you're really saying is "just like it always used to be, just better."
>
> And I want a pony.
>
> ___
> 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] Controlling use of SHA-1

[Viktor Dukhovni]

> On Oct 22, 2015, at 2:18 PM, Andrei Popov  wrote:
> 
> What if we just made an explicit exception for root cert hash algorithms and 
> not constrained them by the client's alg list?

Yes, that would be substantially less bad.  I still don't see any compelling 
reason to shift chain validation policy from the verifying peer (typically 
client) to the subject (typically server).  The subject supplies its 
credentials good or bad, and the *verifier* enforces the right policy.

Indeed if we rely on servers never sending weak creds, clients might be lazy 
and vulnerable by not checking that they got strong creds.  The enforcement 
belongs in the verifier.

And yes, to repeat agreement with Andrei's specific point, exempting root-CA 
self-signatures would be substantially less bad than disallowing various 
signature algorithms globally.

-- 
Viktor.



-- 
Viktor.



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

[TLS] re

[Sultana Parveen]

it ok

Sent from Outlook___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Controlling use of SHA-1

[Yoav Nir]

> On 22 Oct 2015, at 9:26 PM, Watson Ladd  wrote:
> 
> 
> On Oct 22, 2015 2:20 PM, "Salz, Rich"  > wrote:
> >
> > > If we (okay, not "we", library implementors) require explicit application 
> > > opt-
> > > in to TLS 1.3, the adoption rate is probably not going to be very good.  
> > > So, yes,
> > > I think applications should start using TLS 1.3 without any changes.
> >
> > And what about 0RTT?  Removed support for some crypto?  Various other 
> > semantic changes?
> 
> If you don't enable 0RTT support and ignore removed crypto, what breaks? Most 
> apps don't use renegotiation anyway?
> >
> > What you're really saying is "just like it always used to be, just better."
> >
> > And I want a pony.
> 
> Most applications want a simple API that hides all the complexities of TLS. 
> If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't 
> cause problems for those apps which said "you take care of it”.
> 
That is true only if your application’s client component and server component 
are using the same library. That is not guaranteed in a protocol. Specifically 
that is not the case with the web.

There are some version intolerant servers out there that will choke on seeing a 
TLS 1.3 ClientHello. If the client uses some library (like OpenSSL) and you 
upgrade to OpenSSL 1.2.0 that has TLS 1.3. All of the sudden your application 
is broken. On the web this means that some websites don’t work.  Do you live 
with the application being sometimes broken?  Do you make some downgrade dance? 
Hard question, and one that the application needs to answer. 

In any library it’s a major problem if an API call fails in the new version of 
the library where it would succeed in the old version. In a library 
implementing a protocol this could happen because of the network, because of 
middleboxes implementing their own version of “sanity” on the traffic, or 
because of peers that might have a different interpretation of the previous 
standard.

Yoav

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

Re: [TLS] Controlling use of SHA-1

[Martin Thomson]

On 22 October 2015 at 11:17, Watson Ladd  wrote:
> Ideally, yes. Applications never cared about what was happening, but wanted
> a "secure this channel" magic call.


I think that this is conditionally true.  If you are using TLS 1.2
with reasonably modern practices, then getting TLS 1.3 should be easy.
However, if you are relying on MD5 working, or limiting cipher suites
to RC4, then expect some pain.

For NSS, we probably won't turn TLS 1.3 on by default straight away,
but once it is stable, I expect that we will.  Applications that use
the defaults will get 1.3 at that point and not have to worry about
breakage.

Of course, we will be careful not to use 1.3 if things aren't
configured correctly (PFS disabled = no 1.3, etc...) This might not be
easy to perfect, but I believe that this is a goal that is worth the
extra effort.

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

Re: [TLS] Controlling use of SHA-1

[Bill Frantz]

On 10/23/15 at 2:02 PM, ynir.i...@gmail.com (Yoav Nir) wrote:

That is true only if your application’s client component and 
server component are using the same library. That is not 
guaranteed in a protocol. Specifically that is not the case 
with the web.


There are some version intolerant servers out there that will 
choke on seeing a TLS 1.3 ClientHello. If the client uses some 
library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that 
has TLS 1.3. All of the sudden your application is broken. On 
the web this means that some websites don’t work.


This incompatibility cuts both ways. Another way of looking at 
it is that all of a sudden your website has lost viewers and you 
should fix your problem. Perhaps I am unusual, but if I go the a 
website that doesn't work, I usually conclude that I don't need 
to see that web site. My problem is too little time, meaning I 
don't want to bleep with things that don't work, not extra time 
to futz with different browsers to get things working.


Cheers - Bill

-
Bill Frantz| Airline peanut bag: "Produced  | Periwinkle
(408)356-8506  | in a facility that processes   | 16345 
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, 
CA 95032


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

Re: [TLS] Allow NamedGroups from the server?

[Dave Garrett]

On Thursday, October 22, 2015 09:29:22 am Eric Rescorla wrote:
> From an implementation perspective, I wouldn't be surprised if client
> implementations choked on the server sending this. [...]

Hence my side-note that we should be explicit that it's for TLS 1.3+ (even if 
it's implicit elsewhere).

On Thursday, October 22, 2015 01:36:18 pm Martin Rex wrote:
> Andrei Popov wrote:
> > Then my argument would be: why send extra bytes in each ServerHello
> > when TLS client auth is not used most of the time? In this case,
> > CertificateRequest seems to be a better place.
> 
> I'm perfectly OK with the server _not_ sending/including a TLS extension
> "Supported Elliptic Curves" in ServerHello if the server is not going
> to request a client certificate.

Yes, I would expect we want it in TLS 1.3+ ServerHello (or EncryptedExtensions) 
IFF the server is going to request a client cert.


Dave

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

Re: [TLS] Controlling use of SHA-1

[Dave Garrett]

On Thursday, October 22, 2015 02:18:30 pm Andrei Popov wrote:
> What if we just made an explicit exception for root cert hash algorithms and 
> not constrained them by the client's alg list?

+1

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

Re: [TLS] Controlling use of SHA-1

[Viktor Dukhovni]

On Thu, Oct 22, 2015 at 06:40:25PM +, Salz, Rich wrote:

> > Most applications want a simple API that hides all the complexities of
> > TLS. If OpenSSL had done that, then it would be easy to see how enabling
> > 1.2 won't cause problems for those apps which said "you take care of it".
> 
> As someone with a long history of building, influencing, and using libraries
> and their API's, this is not easy.

Binary compatibility is difficult, and requires maintaining legacy
versions of interfaces with cross-platform symbol versioning and
related magic that transcends the release engineering cycles
available to OpenSSL at this time.

That said, source compatibility is a fairly reasonable requirement.

By and large for applications doing simple things, OpenSSL remains
source compatible all the way from 0.9.5a to "master" (soon to be
1.1.0).  Postfix, which uses OpenSSL in a rather more sophisticated
way, has relatively minor adaptations to deal with source compatibility
changes from the 0.9.7 time-frame to the present (we've dropped
support for older OpenSSL versions that was present in earlier
Postfix releases, otherwise that would be 0.9.5 to the present).

Enabling TLS 1.2 (in OpenSSL 1.0.1) caused no fundamental problems
for Postfix, it largely continued to work as-is.  IIRC the padding
extension was needed in 1.0.1g to deal with interoperability with
some IronPort systems that had issues with large client HELLO
messages solved by padding.  The much larger list of ciphersuites
also caused pain with some rather dated Microsoft Exchange 2003
servers that were still in use.  But on the whole the transition
just worked, as it should have.

So recompiling a package against an OpenSSL that supports TLS 1.3,
and fixing occasional issues with now opaque data structures hidden
behind new accessors, should be sufficient for a largely unchanged
application to use TLS 1.3 with no explicit code changes to do so.

> I still want a pony.

I expect to report that Postfix works as-is when OpenSSL is released
with TLS 1.3.  This is not an unreasonable expectation.

If TLS 1.3 does not interoperate with opportunistic TLS clients
when servers are configured with pre-existing self-signed SHA-1
certificates, then IMHO the specification is broken.

If TLS 1.3 pig-headedly forbids sending non-root SHA-1 certs, and
OpenSSL with TLS 1.3 negotiates TLS 1.3 when a server has only a
CA-issued certificate signed with SHA-1, then OpenSSL is broken,
for it should then have worked around the specification brain-damage
by selecting TLS 1.2 (presumably the client still supports that).

I am perplexed that folks desperately want that server with that
SHA-1 cert to not be able to use TLS 1.3.  Surely, the decision to
not trust that cert (if certs are being checked at all) belongs in
the client.

Provided that weak self-signatures are not proscribed, I am resigned
to "come what may" if nobody else thinks that proper segregation
of duties is important, and that putting up some needless roadblocks
to TLS 1.3 use is the price of "progress".

-- 
Viktor.

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