Re: [TLS] A question for TLS middle-box/middleware vendors/implementers

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Yoav,

Thanks for the answers - much appreciated.

On 27/01/2018, 19:31, "Yoav Nir"  wrote:
> The length field is byte-aligned. So any implementation of a TLS
> parser or TLS proxy will do one of two things:
> 
> 1. Consider the MSB to be a must-be-zero bit and drop any length field
> that has it set as faulty.
> 
> 2. Ignore text about limits on length and assume the record is that
> big. Depending on what field that is, this may cause a drop on some
> other sanity check.
> 
> As always there’s option #3 (crash), but the industry is getting
> better at avoiding that.
> 
> You seem to want the behaviour that the middlebox masks out the
> must-be-zero bits and considers only the relevant length bits. I don’t
> think that would pass code review at my former employer.

What I was thinking was rather "once handshake is done and client has
successfully passed the SNI checks, just blindly copy the byte stream
across." I had this specific mental model (that of an HTTPS filter) in
my head, which of course is just one of many.

If the use case is "check for data exfiltration or covert channels",
then the box is probably going to be a fully-fledged interception proxy.
In that case the parser can't be sloppy, and the bit will not go through
unnoticed (as you correctly note above).

But - pardon a naive mind -  these look like the kind of boxes that you
can't just switch on and forget about.  Instead, I'd imagine you need to
keep their release cycle aligned with that of the endpoints, especially
browsers, which tends to be pretty aggressive.  (But yes, one thing is
the vendor release cycle, and a completely different one is the network
operator's upgrade schedule...)

Since you are here, and you have amassed a considerable amount of wisdom
in this space, I have a further question: Is, in your opinion, DTLS in a
better spot than TLS WRT the use of that bit?

Cheers and thanks again

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

[TLS] A question for TLS middle-box/middleware vendors/implementers

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi TLS middle-box/middleware folks,

If length's MSB in a D?TLS{Ciphertext,Plaintext,Compressed} record is
set, how does your software react?

Is it going to drop the session/record or not bothering at all?

I'm trying to understand a bit better whether and when it'd be safe to
grab that bit and give it new semantics (e.g., for signalling the
presence of a DTLS connection-id, an ext-header, or anything else
really) and your answers would help shedding some (*) light on the
matter.

Based on previous experience on similar (but not identical) changes to
the record format, Adam ([1], [2]) suggested that this bit is likely to
have already ossified in TLS, whereas DTLS might be still OK.  So, I'm
curious to hear from those who own the boxes' logics if they share the
same opinion - in particular if DTLS is in better shape than TLS?

Thanks in advance for your time.

(*) I'm pretty sure not every TLS middle-box vendor on earth is
subscribed to this list and, even among those who are, not everyone
might be willing or able to share this information with the wider
community.  This is to say that I'm aware of the limited value a poll
like this has, but I'm not in a position to do a large-scale measurement
campaign at the moment, so better start from somewhere... OTOH, I think
there is a valuable discussion to be had in cases like this with folks
that don't own the endpoints but are going to (or have already) put
their logics on the e2e path, so hopefully I'm not wasting everyone's
time :-)

cheers, t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg25299.html
[2] https://www.ietf.org/mail-archive/web/tls/current/msg25304.html

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

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 24/01/2018, 15:53, "alang...@gmail.com on behalf of Adam Langley" 
<alang...@gmail.com on behalf of a...@imperialviolet.org> wrote:
> On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote:
> >
> > A few months ago, Nikos (can't remember if on this list or on a side
> > conversation) came up with this thought of a generic way to extend
> > the TLS/DTLS record header.  So, I've stolen his idea and written it
> > up in [1] with the intention of using it to make room for the
> > connection-id.
> 
> Our experience with middleboxes suggests that this is likely to fault
> afoul of many flaws in these products if deployed with TLS on the
> wider internet.

Thanks for the insight.

I have thought a bit about this possibility when doing the write-up and
the "MUST NOT be used during handshake" was meant exactly to minimise
the possible impact of middle-boxes during session establishment.

So, the chances to survive handshake should be the same as usual.

After session establishment, the only thing that might look suspicious
to an on-path box is the invalid length.

Do you think this is likely to cause havoc?  Or, in your experience,
middle-boxes tend to not interfere after the TLS channel is up?

cheers

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

[TLS] extended headers for (D)TLS (and their use with connection-id)

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

How to make the existence of a connection id explicit on the wire?

We have looked at a few different approaches - in reverse hackery order:
defining new content types, using an invalid length and bumping the
version number.

Each of them comes with its small or big complications but, irrespective
of that, the basic trouble we have here is that the lack of spare bits
in the record header forces us to override semantics of existing fields
in a way that smells wrong.

A few months ago, Nikos (can't remember if on this list or on a side
conversation) came up with this thought of a generic way to extend the
TLS/DTLS record header.  So, I've stolen his idea and written it up in
[1] with the intention of using it to make room for the connection-id.

At a first glance, it seems to work quite smoothly and has a pretty
compact encoding (see [2] for the details), which would make it my first
choice over all other candidates.

Please have a look (the draft shouldn't take more than 5-10 minutes of
your time) and provide feedback if you feel like.

Thanks, cheers

[1] https://tools.ietf.org/html/draft-fossati-tls-ext-header-00
[2] https://tools.ietf.org/html/draft-fossati-tls-ext-header-00#section-3.4

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 03/11/2017, 09:28, "TLS on behalf of Martin Thomson"  wrote:
> On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell  wrote:
> > It was my understanding that it is precisely this sort of problem
> > that this draft was attempting to address. Explicit marking would
> > solve this.
> 
> Yes, and the connection ID is that marking.  The contention - I think
> - is what to do when there is a mix of marked connections and
> unmarked.

Specifically, the two lines of contention seem to be:
- On the receiver side, whether to favour survival of CID v non-CID
  bearing sessions;
- Packet analyser friendliness (i.e., being able to correctly parse
  the stream without requiring it to keep state.)

Cheers

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Martin,

sorry for taking so long to replay.

> On 18/10/2017, 09:08, "Martin Thomson" <martin.thom...@gmail.com>
> wrote:
> 
> On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote:
> > This is quite similar to the trial and error / heuristic that I was
> > mentioning in [1].
> 
> You didn't mention 5-tuples.  And it isn't trial and error: you use
> 5-tuple as your primary key and use connection ID to latch.

We seem to have a slightly different opinion on the meaning of trial and
error :-)  But more importantly, we seem to disagree on whether parsing
a binary header is orthogonal to context lookup (either via 5-tuple or
CID) or not.

> > Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails
> > to recognise A.1 as CID-enabled and sends it forward to the crypto
> > handler when it shouldn't.
> 
> As I said before, any connection without a connection ID monopolizes
> that 5-tuple making it inaccessible to other connections.  I think
> that in this case: too bad.

I'm not sure I agree with that.  CID should be the tie breaker exactly
in these situations.  When something like that happens, if your
implementation supports CID it should win/survive over one that doesn't.

> > And the already discussed limitations:i
> > - Fragility on corner cases (e.g., the 5-tuple swap above);
> 
> I don't see how you can avoid this in the general case.  Any
> connection without connection ID is going to be hard to correlate if
> it moves.  As for the connection that does have a connection ID but
> moves on top of a connection that doesn't, I don't think that is an
> acceptable loss.

I think you mean "I do think that is an acceptable loss", or "I don't
think that is an unacceptable loss", right?
 
> > - Forcing middleware to keep state;
> > - Breaking wireshark & co unless they can see the whole session;
> 
> Both of these are acceptable to me.  Unless you can describe a
> middlebox use case that needs access to this information and can't
> deal with the solution that I described.  Wireshark and co will need
> to see the handshake if they want to decrypt and that's the only case
> that is important.

For diagnostics, it'd be pretty useful if one could filter a capture by
CID and follow *that* session among lots of others.  Irrespective of
what's in the encrypted payloads (which one can probably get from the
endpoint, if needed).  This is one use case that seems very useful to me
and doesn't require wireshark to keep state.  I'm not saying that there
are no work-arounds: we know how to make do with pcap filters.  But I'd
prefer to design something that is simple and cheap to implement and use
in the first place, if possible.

What I'm asking for is a codepoint and an explicit length for the CID,
i.e., a total +1 byte per 1.2 record on the wire.  I'm not sure the
tiny saving we get with the current proposal justifies the increase in
complexity.

> > - (Depending on the use case, the cost of the two lookups per record
> >   on the parsing might have a performance impact.)
> 
> The second lookup only happens after a migration.

In the IoT use cases, re-binding during a sleep cycle is the common
pattern, so the second lookup is going to be fairly common.

> I neglected to mention that successful use of a connection ID causes
> the 5-tuple to be assigned to that connection; there's a trick there
> in that you need to watch for reordering, but it saves the double
> lookup.

The thing that makes me slightly nervous is that we are talking about
doing trial & errors (at least in my definition of the term) and other
implementation tricks to achieve the very trivial task of parsing a
binary header.  This is what makes red flags pop up and makes me
think that we can do better.

Cheers

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 17/10/2017, 22:35, "Martin Thomson" <martin.thom...@gmail.com> wrote:
> On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote:
> > The following case (NAT box reboot) is problematic:
> >
> > 1. Application '1' on host A (A.1) uses DTLS+CID with application
> >'1' on host B (B.1);
> > 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
> > 3. The NAT box reboots (all previous 5-tuple mappings are lost);
> > 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
> >meanwhile);
> >
> > How is B.1 supposed to correctly interpret the bytes starting at
> > offset +11?  (For what it knows, it could be CID from A.1 or the
> > length field from A.2.)
> 
> I don't think that this is a problem.
> 
> connection = five_tuples.lookup(packet.five_tuple)
> if (!connection) {
>   connection = 
> connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length])
> }
> if (!connection) {
>   // is this a ClientHello?  otherwise drop it
> }

This is quite similar to the trial and error / heuristic that I was
mentioning in [1].

Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails to
recognise A.1 as CID-enabled and sends it forward to the crypto handler
when it shouldn't. 

It looks simple, but it introduces subtle complexity in that parsing is
not self-contained anymore: it depends on a couple of things (the
connection_ids and five_tuples stores) that in principle should have
nothing to do with making sense of an incoming record.

And the already discussed limitations:
- Fragility on corner cases (e.g., the 5-tuple swap above);
- Forcing middleware to keep state;
- Breaking wireshark & co unless they can see the whole session;
- (Depending on the use case, the cost of the two lookups per record
  on the parsing might have a performance impact.)

> > I might be missing something fundamental here, but isn't the length
> > encoded in the CID field on the wire?
> 
> Not by my understanding.  There isn't any need (the intent is to have
> the CID only consumable by the entity that created it, and any others
> that it collaborates with, like a load balancer).

You are right.  For some reasons, I was implying cid was encoded as a
variable-length array.  That said, I don't think saving 1 byte here is
worth the self-inflicted pain of making tshark unusable :-)

Cheers

[1] https://www.ietf.org/mail-archive/web/tls/current/msg24575.html

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nikos,

On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" 
 wrote:
> Another worrying feature is that the client can make the server send
> up to 255 verbatim bytes on the wire of his choice. Why was this
> feature added? Are there use cases related with it (intro doesn't
> mention any), or it was only thought as a make it as generic as
> possible approach? If it is the latter, I'd recommend to provide a
> simple approach that covers the described use cases.
> 
> The same argument applies to the server being able to set such a long
> sequence of verbatim bytes to each of the client packets.

I'd like to get a better understanding of your concern here.

Is it size?

Or is that it creates a potential sub-channel for sending identifying
information?

If the latter, it doesn't look much different from Random (except it's
larger)?  And then it gets hashed in the finished message, so, the room
for a third party to fiddle with it seems really limited.

Exactly, what risk do you foresee?

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Martin,

On 17/10/2017, 00:42, "Martin Thomson"  wrote:
> Thomas mentioned a heuristic, but I don't think that we need that.
> The only case that is difficult, and it's one that you might not care
> about, is one where a connection migrates to the same 5-tuple as an
> another connection.  There, you will match to an existing connection
> and find that the packet doesn't decrypt.  If the connection that you
> have associated with the 5-tuple supports and uses a connection ID,
> you can recover without trial decryption.  Otherwise, you just have to
> drop the packet when it doesn't decrypt.  (You could look up all the
> connections without connection IDs and use trial decryption, but why
> bother spending the effort and undermine the strength of your ciphers
> in that way.)

The following case (NAT box reboot) is problematic:

1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on
   host B (B.1);
2. Application '2' on host A (A.2) uses plain-old DTLS with B.1;
3. The NAT box reboots (all previous 5-tuple mappings are lost);
4. B.1 receives a record from A.1 (whose 5-tuple has changed in the
   meanwhile);
 
How is B.1 supposed to correctly interpret the bytes starting at offset
+11?  (For what it knows, it could be CID from A.1 or the length field
from A.2.)
 
That's where the heuristic I mentioned in the other email comes in,
I think.

> Packet inspection boxes will have maintain state, I don't see a way
> around that.  The point here being that you need state to know how
> long the connection ID is, as well as how long it is.

I might be missing something fundamental here, but isn't the length
encoded in the CID field on the wire?

Cheers

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Matt,

On 13/10/2017, 14:15, "TLS on behalf of Matt Caswell"  wrote:
> Recently I met with Yin Xinxing and we have had much the same
> conversation about what a Connection ID draft would need to do, and
> how we could detect its use on the wire. Mechanisms we talked about
> included setting something in the "length" field, using ContentType or
> using version. IMO using "length" is just horrible. I'm also not keen
> on version - it further complicates the "is this version greater than,
> equal to, or less than this other version" question. It's already
> slightly complicated in code that implements both TLS and DTLS due to
> DTLS versions being high and decrementing for a new version. I foresee
> lots of subtle bugs and problems from reusing "version". In my mind
> ContentType is the way to go.

Re: the length hack.  I agree with you that it is not the right way to
go here.

Re: CT vs version, a couple of quick thoughts:
- I'm still unconvinced that CT is the right place to signify a change
  in the parsing logics that effectively spans all CTs;
- Besides, ISTM that version is the only field that would potentially
  work for 1.3 as well as 1.2?

Cheers,

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

Re: [TLS] Connection ID Draft

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

First, thanks for the draft.

As discussed off-list, wrt framing / wire format, we probably have an 
opportunity to do slightly better than this, at least for 1.2.

The thing is that, since there is no flag in the record that says: "I'm 
carrying a CID", a receiver has no explicit way to know whether a record is 
coming from a CID-enabled session or a legacy-DTLS.

This ambiguity complicates the decoder because the receiving end now needs to 
implement a heuristic like:

-  let's first assume at offset +11 we have a CID

-  and then lookup the SAs store using this "maybe" CID

-  if found, OK (*), go on with the parsing

-  if not, fall back to assuming at offset +11 we have the length field 
and go on parsing

This is not ideal for a bunch of reasons:
1. For every incoming record, the receiver needs to lookup the CID store 
just to parse the record;
2. The implementation is more complicate;
3. Heuristics are intrinsically fragile and are known to deal badly with 
corner cases (think the many creative ways the many moving parts can conspire: 
5-tuple reshuffling because of NAT rebinding, lost state due to reboot/restart 
of one or more nodes, co-existing CID and legacy DTLS);
4. Wireshark & co will choke because they typically don't have enough 
context to handle the two different framings;

To solve this, we'd need a place in the wire image of the record with 
semantics: "I'm carrying a CID."

In 1.2, we could use CT or version.  (In 1.3, that would not be possible 
because the diet header doesn't have them - too bad.)  To me it'd make slightly 
more sense to use the version. (I had previous discussions on this topic with 
Nikos and he told me that though anyconnect does this version override for some 
reasons, there is no reported conflict with middle-boxes.)  Also, there would 
be only one code-point to allocate, instead of separate code-points for each 
CID-enabled content type variant.  I'm happy to be convinced of the opposite, 
though.

I guess my main point here is to make sure we do as much as we can to allow 
simple, efficient, robust implementations, which are also, en passant, 
Wireshark-friendly, and leave heuristics-based approaches only for when there 
is no real alternative.

Cheers, t

(*) assuming CID is entropic enough, which may or may not be the case.


On 13/10/2017, 00:13, "TLS on behalf of Eric Rescorla" 
 on behalf of 
e...@rtfm.com> wrote:

Hi folks,

I have just posted a first cut at a connection ID draft.
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00

Comments welcome.

-Ekr



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

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nick,

Your write-up is spot on, thanks.

Let me comment on a few points:

“How much Delegated Credentials can be rotated and diversified inside an 
organization is only limited by the operational ability of the organization 
that has control of the EE private key.”

The self-service/agile nature of D-C is great. With that, though, comes a cost 
of ownership that maybe not all players can afford.

- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must 
provide proof of domain possession to CA vs. internally managed credential 
minter for delegated credentials).

There should be ways to mitigate this, say allowing the next S-T in line to be 
available “long enough” before it becomes active.

-- There is no fallback if the CA has outage. With delegated credentials you 
can fall back to a LURK-style protocol with the long-lived certificate key.

I understand the logics but, since LURK boxes don’t scale, the cost to cover 
your entire footprint for the sporadic cases when the CA is down might be a bit 
prohibitive.

Cheers, t


On 18/07/2017, 14:35, "Nick Sullivan" 
<nicholas.sulli...@gmail.com<mailto:nicholas.sulli...@gmail.com>> wrote:

Thomas,
Thanks for your comments. Let me see if I can summarize them:
- A disadvantage of delegated credentials vs short-lived certs is that it 
requires client opt-in. This is also a disadvantage of proxy certificates. If 
client support is below 100%, a LURK-type system may be required to keep 
long-term private keys off TLS termination endpoints.
- A disadvantage of delegated credentials is that it requires software updates 
on both client and server. This is also a disadvantage of proxy certificates. I 
think this is covered by my point below: "Short lived certs work with existing 
libraries, no new code changes."
- An advantage of short-lived certificates is that there is an audit log by a 
third party (either the CA's internal logs and optionally Certificate 
Transparency logs).
I should state that short-lived certificates are possible right now and it's 
supported by some CAs, though not necessarily at the scale needed to provide, 
say, a unique 7-day certificate for each server of a large Internet company. 
This draft's advantages apply most strongly to organizations who don't want to 
tie their ability to have functional TLS on the ability for CAs to maintain 
high-availability issuance services.  How much Delegated Credentials can be 
rotated and diversified inside an organization is only limited by the 
operational ability of the organization that has control of the EE private key.

Nick

On Tue, Jul 18, 2017 at 1:40 PM Fossati, Thomas (Nokia - GB/Cambridge, UK) 
<thomas.foss...@nokia.com<mailto:thomas.foss...@nokia.com>> wrote:
Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per 
se.

I had expressed a couple of concerns at the time the call for adoption was 
first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" 
<tls-boun...@ietf.org<mailto:tls-boun...@ietf.org> on behalf of 
nicholas.sulli...@gmail.com<mailto:nicholas.sulli...@gmail.com>> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who 
were in the proxy certificates and short-lived certs camp, and we think there 
is now more agreement that the mechanism described in this draft is superior to 
the alternatives. I've included a summary of some of the pros and cons of the 
approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than 
limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as 
part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints 
enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated 
creds (which can easily be implemented in TLS as demonstrated by the 3 
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE 
cert. This is a binding weaker than delegated credentials which includes a 
signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially proble

Re: [TLS] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Nick,

I am not against delegated credentials, in fact I think it’s a good thing per 
se.

I had expressed a couple of concerns at the time the call for adoption was 
first issued [1], which I think are still valid.

Could you please comment on / add them to your pro-cons analysis?

Cheers, thanks,
t

[1] https://www.ietf.org/mail-archive/web/tls/current/msg22966.html

On 18/07/2017, 12:06, "TLS on behalf of Nick Sullivan" 
 on behalf of 
nicholas.sulli...@gmail.com> wrote:

Sean,
We've had some additional discussions in person here at IETF 99 with folks who 
were in the proxy certificates and short-lived certs camp, and we think there 
is now more agreement that the mechanism described in this draft is superior to 
the alternatives. I've included a summary of some of the pros and cons of the 
approaches:
Proxy certificates vs. Delegated Credentials
Pro proxy certificates:
- Already deployed in some industries, though not on the Web.
- Fits the conceptual model that public key == certificate.
Con proxy certificates:
- Proxy certificates adds additional complexity to the delegation other than 
limiting the time period (full X.509, additional constraints  such as hostname).
- Encourages implementers to reuse PKIX libraries rather than build code as 
part of TLS:
-- There have been problems and inconsistencies around pathlen and constraints 
enforcement in existing PKIX libraries.
-- Modifying these libraries is more complex and risk prone than delegated 
creds (which can easily be implemented in TLS as demonstrated by the 3 
interoperable implementations at the IETF 98 hackathon).
- In proxy certificates, pathing is SKI dependent, not directly tied to EE 
cert. This is a binding weaker than delegated credentials which includes a 
signature over the EE certificate.

Short-lived certs vs. Delegated Credentials
Pro short-lived certs:
- Short lived certs work with existing libraries, no new code changes.
Con short-lived certs:
- Not widely available from CAs, especially for EV.
- Potentially problematic to the CT ecosystem (all certificates must be logged 
in CT, which may bloat them).
- Introduces a high-risk operational dependency on external party:
-- Requires frequent exchanges with an external Certificate Authority (must 
provide proof of domain possession to CA vs. internally managed credential 
minter for delegated credentials).
-- There is no fallback if the CA has outage. With delegated credentials you 
can fall back to a LURK-style protocol with the long-lived certificate key.

Given these comparisons, we think the proposed draft is the superior option and 
would like to continue the discussion about adopting it.

Nick

On Fri, May 19, 2017 at 12:58 AM Sean Turner 
> wrote:
All,

During the WG call for adoption, a couple of questions were raised about 
comparison/analysis of sub-certs versus proxy and/or short-lived certificates.  
There is some discussion currently in the draft, but the chairs feel that these 
issues need further discussion (and elaboration in the draft) prior to WG 
adoption.  So let’s keep the conversation going.

J

> On Apr 12, 2017, at 15:31, Sean Turner 
> > wrote:
>
> All,
>
> At our IETF 98 session, there was support in the room to adopt 
> draft-rescorla-tls-subcerts [0].  We need to confirm this support on the list 
> so please let the list know whether you support adoption of the draft and are 
> willing to review/comment on the draft before 20170429.  If you object to its 
> adoption, please let us know why.
>
> Clearly, the WG is going to need to work through the trade-offs between 
> short-lived certificates and sub-certs because both seem, to some, to be 
> addressing the same problem.
>
> Cheers,
>
> J
>
> [0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-subcerts

___
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] Suggestions in draft-mavrogiannopoulos-tls-cid

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Ashok,

Thanks very much for your comments.

See inline.

Cheers, t

On 07/07/2017, 14:44, "Raja ashok" 
> wrote:

Hi Nikos, Hannes & Thomas,

This ConnectionID concept is really a useful feature for a client node which 
faces a change in transport and network layer. I am having few suggestions in 
the proposed draft, which are listed below.

1) In section 3 of this draft, explains about the modification in 
"DTLSCiphertext" structure. I feel instead of modifying existing DTLS and TLS 
record header, we can directly introduce a new record type (ContentType) for 
app data (application_data_with_cid(25)).

[tf] Why do you think a new record type would be better than the present 
construction?  (BTW, we would also need a new alert_with_cid, I guess.)

For this new record type, we can propose a modified record header for both TLS 
and DTLS.

[tf] If you are already modifying the record header, I am not sure why you also 
need to add new content type(s)?

2) More over section 3 says modification only in "DTLSCiphertext", not for 
"TLSCiphertext". I hope this CID mechanism should be used for both TLS and 
DTLS. Because this transport layer change problem is there for TLS based 
applications (HTTPS) also in Smartphone(when it switches from Wifi to LTE). But 
this TLS application problem is solved by MPTCP, but I dont think all 
webservers are supporting this MPTCP. So I feel CID is required for both TLS 
and DTLS.

[tf] In principle I’m not opposed to open the solution space to TLS, but we 
need to work out the implications.

3) As part of defining new record type, we can remove some unused fields like 
version, epoch. After removing epoch we can mandate that  both entity should 
not start renegotiation. Sample design for new record header with CID is 
mentioned below
struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint48 sequence_number;
uint16_t record_length;
} DTLSRecordHeader;
opaque CID <4..8>;

struct {
uint8_t ContentType;
uint8_t CID_len;
CID cid;/* Length varies from 4 to 8 (or 16) */
uint16_t record_length;
} TLSRecordHeader;
opaque CID <4..8>;

4) Another option is we can keep CID_len as 4 bit to represent a CID of size. 
And this 4 bit can be placed in the MSB of the CID field.

uint8_t CID_len:4;
CID cid;/* Length varies from 28bit to 60 bit (or 124bit) */


5) Section 3.1 and 3.2 talks about the new extensions for negotiating this 
feature support. But I feel no need of new extensions to negotiate this, we can 
make client to add new SCSV cipher in its cipher list. If server accepts then 
after handshake the first application data send by server should be of type 
application_data_with_cid(25), which should hold the new record header with 
CID. The same CID should be used by client in the further messasge. If client 
sends the 1st application data after handshake, then it can send application 
data with default record type (application_data(23)). If the first application 
data record received from server is not of application_data_with_cid(25) means 
client should understand that server has not accepted the SCSV proposed. And 
client should continue app transfer with default record type 
(application_data(23)).

[tf] What is the problem with using a new extension?  How would negotiating 
parameters (e.g., CID type, CID length) work in your proposal?

Please provide your comments on this suggestion.

Regards,
Ashok



[ompany_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Hannes,

On 24/04/2017 16:39, "Hannes Tschofenig"  wrote:
> On 04/21/2017 12:48 PM, Ilari Liusvaara wrote:
> > Regarding clients, I think the draft specifies LURK as backup plan
> > for clients that don't support subcerts (which causes some extra
> > latency if triggered).
> I didn't got that impression.

Ilari is correct I think -- the fallback to LURK is what the draft in its
current version seems to imply.

> Isn't this something ACME was trying to solve as well?

We have proposed an extension to ACME that handles the full lifecycle of the
delegation, including the automatic renewal of the trail of short term
certificates.  It works in a pretty straightforward way and doesn't require any
modification in the endpoints' stack.

Cheers, t


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

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

I've read draft-rescorla-tls-subcerts-01 and have a few comments.

It's a well written document and the low-level mechanics look ok.  However,
I think I have a couple of issues with the overall design.

First: it is not self-sufficient.  The fact that clients must opt-in implies
that servers must have a backup plan.  Since keeping the high-value key
material in the same node as the delegate credentials contradicts the basic
security goal, the only realistic fallback is to have a key-server / LURK box
at hand?  But this has the known and already discussed limitations --
complicated setup and operations, scaling issues, single point of failure,
etc. -- which make it inapplicable to some key use cases (CDN).

Second, we need to change the stack at the endpoints.  This might be OK for
browsers, but it's a bit more problematic when the UA is an STB or a
residential gateway, as these things tend to have much slower release and
upgrade cycles.

With regards to WG adoption, I guess I'm neutral.  I think it doesn't hurt
to have something like this, but for the reasons stated above, I'm not sure
it provides a solution to the LURK problem.

Cheers, t

PS: It'd be nice if the document discussed the implication of the "unregulated"
delegation mechanism especially with regards to its auditability.

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 16:50, "Salz, Rich"  wrote:
> > Speaking as one of the co-authors of [1]: it is not completely clear to me
> > what is the limitation in CT that would prevent it to cope with the
> > pervasive use of short-term certificates.  Can anyone shed a light on this?
> 
> I believe the concerns are scaling log servers and perhaps needing to
> "rotate" them if, say, 90% of their tree is invalid in a year.

Thanks Rich.  I need to double check that, but I guess there are remedies for
the issues you mention -- e.g., adding more logs / having separate logs for
very short term stuff.

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

Re: [TLS] draft-rescorla-tls-subcerts-01

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

On 21/04/2017 11:48, "TLS on behalf of Ilari Liusvaara"  wrote:
On Fri, Apr 21, 2017 at 10:37:21AM +0200, Hannes Tschofenig wrote:
> > What is also not clear to my why some of the certificate management
> > protocols, which provide the necessary level of automation, cannot be
> > used with CAs to request short-lived certificates.
> 
> AFAIK, that would cause issues with CT and OCSP signing.

Speaking as one of the co-authors of [1]: it is not completely clear to me what
is the limitation in CT that would prevent it to cope with the pervasive use of
short-term certificates.  Can anyone shed a light on this?

Cheers, thanks,
t

[1] https://tools.ietf.org/id/draft-sheffer-acme-star-00.txt

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