Re: [TLS] Should we require implementations to send alerts?

[Hubert Kario]

On Friday 18 September 2015 15:13:37 Bill Frantz wrote:
> On 9/18/15 at 4:27 AM, hka...@redhat.com (Hubert Kario) wrote:
> >except that a TLS1.3 version intolerant implementation won't
> >show its ugly head until TLS1.4 gets deployed
> 
> Is there a reason a test suite can't offer TLS 1.4, even if we
> don't know what it is?

There is no reason. In fact, any test suite should basically start with 
this (it being one of the very first fields the server needs to handle).

> The TLS implementation under test should
> gracefully step back to TLS 1.3.

correct

-- 
Regards,
Hubert Kario
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] Should we require implementations to send alerts?

[Hubert Kario]

On Friday 18 September 2015 13:24:33 Brian Smith wrote:
> On Fri, Sep 18, 2015 at 4:36 AM, Hubert Kario  
wrote:
> > On Friday 18 September 2015 00:58:19 Martin Rex wrote:
> > > Easier troubleshooting is IMO a sufficient rationale to justify
> > > existence of the alert mechanism and a "SHOULD send the alert
> > > before
> > > closing the network connection".
> > > 
> > > A "MUST send fatal alert" requirement, however, would be silly
> > > (and
> > > will be void in face of rfc2119 section 6 anyway).  What would be
> > > the semantics of such a requirement anyway?
> > 
> > That's true only if you ignore the situation when TLS 1.4 or TLS 2.0
> > is deployed.
> 
> > So yes, it's no a direct interoperability issue, but it will become
> > one
> > in the future.
> 
> Given a *conformant* TLS 1.3 implementation, that kind of
> interoperability problem could only happen if the TLS working group
> specifically designed it to happen. In particular, a conformant TLS
> 1.3 implementation must accept larger values of
> ClientHello.client_version.

Given that there is no *conformant* TLS 1.2 implementation that is 
widely deployed[1], I won't hold my breath for there being many TLS1.3 
ones either.

We don't live in ideal world, lets build protocols that can handle 
breakage. Lets make specifications that have the sticks that we can hit 
developers with when they do wrong.

 1 - NSS, SChannel and OpenSSL, all ignore some MUSTs in TLS1.2
-- 
Regards,
Hubert Kario
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] Review of PR #209

[Geoffrey Keating]

Daniel Kahn Gillmor  writes:

> Consider a server has an ongoing session wrapped in TLS that uses client
> authentication to approve or deny some requests from the client.  It
> remembers what requests the client has made as some sort of relevant
> state.  Let's take an imap server working with a client that has state
> of a "currently-examined folder", but this applies to servers and
> clients with much more complex state as well.
...

I think for such a protocol, you'd want to say that authentication is
not retroactive.

For other protocols, you might want something else.  For example, in a
protocol which uses client authentication for billing, you might want
to treat an authentication half-way through the session as the account
to bill for the entire session.

Some protocols will also want to support multiple identities, and some
will not.  For some protocols a new authentication might want to in
some fashion dis-trust previous authentications, other protocols might
say that all previous authentications are valid until the end of the
session.


I think this is something that TLS should allow higher-level protocols
to specify.  The TLS model could be that each client authentication
happens at a particular point in the session, breaking it up into
segments, and TLS informs the higher-level protocols of where the
segments start and end; it's up to the higher-level protocol to work
out what that means.

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

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

[Daniel Kahn Gillmor]

On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni  
wrote:
> So the client would now need to cache some session data by transport
> address, and other data by name and port.  That's rather complex.

This is already done by HTTP/2 clients, since they can access multiple
servers at the same address:port combination.

> And how often will the same client visit multiple servers at the
> same transport address?

*.github.io, *.blogspot.com, massive CDNs, etc.  It's a common pattern.

> I don't really see this as viable or worth the effort.

I disagree -- the metadata leaked to a passive attacker by mandatory SNI
is a valuable signal.  It is worth trying to protect it.

> I don't think SNI hiding is viable without encryption at the
> transport or network layers.

any encrypted SNI is effectively acting as a shim for transport
encryption, yes.  Then again, TLS is itself "transport layer security",
so we should try to provide it at least as an option.

> And there's still a metadata leak via DNS which may prove difficult to
> address.

The DNS community is working to address the DNS leak in DPRIVE.  The TLS
community should be working to fix its own part of the metadata leak.

  --dkg

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

Re: [TLS] encrypted content type and padding

[Daniel Kahn Gillmor]

On Mon 2015-09-21 04:43:27 -0700, Watson Ladd  wrote:
> Is this actually true in the second pull request? No: a moment of
> actually reading reveals that the string is inside an AEAD encrypted
> packet. There is no way in which this padding could be modified for
> use in a side-channel attack.

In both pull requests, the padding is inside the AEAD encrypted packet.
The intent, after all, is to create a mechanism that provides
uncertainty about the length of the cleartext.

See, for example:

 I Know Why You Went to the Clinic: Risks and Realization of HTTPS
 Traffic Analysis
 
 by  Brad Miller, Ling Huang,  A. D. Joseph, and J. D. Tygar

 http://arxiv.org/abs/1403.0297

 --dkg

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

[TLS] Fall Interim webex/jabber details

[Sean Turner]

Please note that I sent two webex invites one for each day and that they have 
different meeting #s but the same pwd:

Monday:
https://mailarchive.ietf.org/arch/msg/tls/2wD0hlicN7oaBbWO8qKqtXAhfos

Tuesday:
https://mailarchive.ietf.org/arch/msg/tls/mP16zjy9h7eH2y02WTEnTqDKey4

We’re starting at 9 Pacific Time (fingers crossed).

We’ll also be using the tls jabber room: t...@jabber.ietf.org

spt


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

Re: [TLS] Review of PR #209

[Daniel Kahn Gillmor]

On Sun 2015-09-20 22:38:45 -0700, Karthikeyan Bhargavan 
 wrote:
> As dkg points out, dynamically authenticating clients later in the connection 
> brings up
> API issues of how to notify the application about the scope of this new 
> authentication event.
>
> I think it is inevitable that implementation will store the client credential 
> in the session, and
> that the new (authenticated) stream of data will be concatenated to the older 
> (unauthenticated) stream.
> Both of these design choices will lead to the following answers to dkg’s 
> questions:
> (a) all messages in TLS sessions (past and present) will be attested to by 
> every certificate
> (b) all traffic in earlier and future resumed sessions will be attested to by 
> every certificate
>
> In other words, if we do allow this change to client authentication, to be 
> safe, we must analyze the
> resulting protocol *as if* applications will use the authentication event to 
> attest to all
> data, past and present, that may be associated with the data in the current 
> connection.

But this combination is pretty weird for servers to deal with.  For
example:

Consider a server has an ongoing session wrapped in TLS that uses client
authentication to approve or deny some requests from the client.  It
remembers what requests the client has made as some sort of relevant
state.  Let's take an imap server working with a client that has state
of a "currently-examined folder", but this applies to servers and
clients with much more complex state as well.

The client is currently examining folder Y.

Some client identities *do not* have authorization to visit folder X.
others do.

The client requests a change to folder X.

The server rejects the change.

The client subsequently authenticates to an identity that is authorized
to access folder X.

What is the currently-examined folder for this session?

The "easy" (and right) answer here is "folder Y, of course" -- but
telling peers that the authentication should apply retroactively to all
previous data sent suggests that maybe it should be folder X.

This is confusing.  Confusing semantics are bound to lead to problematic
implementations and usage :(

Sorry that this mail doesn't have a better suggestion to offer.

 --dkg

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

[TLS] '15 TLS WG interim materials

[Sean Turner]

I’ve uploaded the slides I’ve received to:

https://www.ietf.org/proceedings/interim/2015/09/21/tls/proceedings.html

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

[TLS] WebEx meeting invitation: '15 Fall Interim

[TLS Working Group]

Hello,

TLS Working Group invites you to join this WebEx meeting.


'15 Fall Interim
Tuesday, September 22, 2015
9:00 am  |  Pacific Daylight Time (San Francisco, GMT-07:00)  |  1 hr


JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=m3a04aa0bc197fc8e2a2c45b34ac5136b
Meeting number: 648 054 164
Meeting password: 1234


JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada) 
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 648 054 164

Toll-free dialing restrictions: 
http://www.webex.com/pdf/tollfree_restrictions.pdf


Add this meeting to your calendar:
https://ietf.webex.com/ietf/j.php?MTID=m1402dc79c4de48b304a8ebebc9a0c793


Can't join the meeting? Contact support here:
https://ietf.webex.com/ietf/mc


IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. By joining this session, you automatically consent to such 
recordings. If you do not consent to being recorded, discuss your concerns with 
the host or do not join the session.


WebEx_Meeting.ics
Description: Binary data
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Review of PR #209

[Martin Thomson]

On Sep 21, 2015 7:02 AM, "Ilari Liusvaara" 
wrote:
> Under such assumption, even dynamic reauth in HTTP/1.1 is unsafe. If
> one additionally assumes causality, dynamic reauth in non-pipelined
> HTTP/1.1 may be safe, but dynamic reauth in HTTP/2 (or HTTP/1.1 with
> pipelining) is still unsafe.

What do you mean when you say "safe" and "unsafe" here?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] WebEx meeting invitation: '15 Fall Interim

[TLS Working Group]

Hello,

TLS Working Group invites you to join this WebEx meeting.


'15 Fall Interim
Monday, September 21, 2015
9:00 am  |  Pacific Daylight Time (San Francisco, GMT-07:00)  |  8 hrs


JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=mf2ecbe12f0cf7a93601297ea89cbf5ce
Meeting number: 642 106 434
Meeting password: 1234


JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada) 
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 642 106 434

Toll-free dialing restrictions: 
http://www.webex.com/pdf/tollfree_restrictions.pdf


Add this meeting to your calendar:
https://ietf.webex.com/ietf/j.php?MTID=m7b586cacef8f6783ed99b91cc96fa0b7


Can't join the meeting? Contact support here:
https://ietf.webex.com/ietf/mc


IMPORTANT NOTICE: Please note that this WebEx service allows audio and other 
information sent during the session to be recorded, which may be discoverable 
in a legal matter. By joining this session, you automatically consent to such 
recordings. If you do not consent to being recorded, discuss your concerns with 
the host or do not join the session.


WebEx_Meeting.ics
Description: Binary data
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls