Re: [cryptography] "There is something Google can do. So they should do it."

[Stephen Farrell]

On 27/11/15 23:43, Jeffrey Walton wrote:
> On Fri, Nov 27, 2015 at 5:47 PM, Greg  wrote:
>> Thought this list would be interested in reading about the roll that Google 
>> played in compromising 100k+ users (in addition to Dell):
>>
>> https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y
> 
> They seem to be missing the issue (if I am parsing it correctly):
> 
>   REDDIT > So you are saying that Chrome should roll out its own
>   REDDIT > cert store because relying on Windows 10's cert store is
>   REDDIT > insecure?
>   REDDIT >
>   REDDIT > Sorry your argument seems very weak and odd to me.
>   REDDIT > It also detracts away from the severity of what Dell has done.
> 
> That's not Chrome or Windows per se. Rather, that it is a feature of
> the Web/Browser security model. In the security model, proxying and
> interception is a valid use case. You can thank the browser
> (in)security engineers for that.
> 
> It not just limited to W3C participants. The IETF just jumped on the
> "proxying and interception is a valid use case" bandwagon with RFC
> 7469, "Public Key Pinning with Overrides"

That is not actually the title of that RFC.

> (https://tools.ietf.org/html/rfc7469). Checkout section 4, and then
> try to find what the override is supposed to do, or additional
> information or guidance on using it.

I'm not a fan of that override stuff myself (which is in 2.6 and
not in section 4 btw) but weren't you yourself [1] a part of that
discussion in the websec wg? While you may have joined in that part
of the discussion too late to affect the outcome, I think
characterising this is "just jumped on ... bandwagon" isn't fair
nor accurate.

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

> 
> Finally, don't look to the IETF to help distinguish the "good" bad
> guys from the "bad" bad guys when a conforming user agent does
> override (or tries to decide if it should override). I've been trying
> to discover that myself. See "How do we differentiate authentic
> servers from proxies performing TLS interception",
> https://www.ietf.org/mail-archive/web/pkix/current/msg33425.html.
> 
> And finally (and either humorously or sadly, depending on your state
> of mind), the PKIX's position is there's no difference between
> authentic server authentication and an imposter pretending to be an
> authentic server. They are happy to allow a CA to issue certificates
> for either usage, even though they appear to be as diametrically
> opposed as you can get.

IMO the above is a mis-characterisation of the situation and of the
recent discussion on the p...@ietf.org mailing list.

My read of that discussion is that a number of people stated a number
of times that no matter how much one would like some bit in a protocol
to distinguish real authentication vs. a MitM with a locally installed
trust point, there's just no way that can work. I saw that you seemed
to disagree with that, but tbh I've no idea how what you want could
work.

What you're after can't be provided by the IETF. I do agree that
implementations could handle overrides differently in ways that
would make it harder do be a MitM.

I'd also point you at RFC2804 and BCP200 which are other relevant
IETF publications.

Cheers,
S.

> 
> The NSA and GCHQ does not need to limit cryptography or algorithms.
> They just need more browser (in)security engineers in more working
> groups.
> 
> Jeff
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
> 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] What's the point of using non-NIST ECC Curves?

[Stephen Farrell]

On 13/10/14 15:51, Derek Miller wrote:
 Like many people, I consider the seed values used to generate the NIST
 Prime curves suspicious.
 However, considering one of the scenarios where these curves might be
 compromised (the NSA knew of weaknesses in certain curves, and engineered
 the NIST Prime curves to be subject to those weaknesses), does it even make
 sense to use ECC at all?
 If the NIST curves are weak in a way that we don't understand, this means
 that ECC has properties that we don't understand.
 Thus, if you don't trust the NIST Prime curves, does it make sense to trust
 any ECC curves at all?

There are performance and implementation reasons (easier to
avoid side-channel attacks) claimed for the additional curves
that are being looked at by the IRTF's CFRG (at the request
of the IETF's TLS, if that's not too acronym laden:-) Those
claims seem credible at least, and are also spurring folks to
look again at implementations of the NIST curves.

S.

 
 I appreciate your responses,
 D
 
 
 
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] STARTTLS for HTTP

[Stephen Farrell]

Forgotten link added below...



On 19/08/14 11:57, Stephen Farrell wrote:
 
 Hiya,
 
 On 19/08/14 07:09, Ryan Carboni wrote:
 It would be secure against wifi eavesdropping. But worse it might instill a
 false sense of security.
 
 Well, protocols don't do that, but user agents (browsers in this case)
 can. However, the httpbis WG are on the topic and have a proposal
 for HTTP/2.0 for opportunistic security [1] that they're working on
 that I don't believe has that problem. (There's no user indication
 at all that its happening.)
 
 I'm not sure why 2817 never took off, but suspect its mostly that
 2818 had already taken off when both were published.
 
 S.

[1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption

 



 On Mon, Aug 18, 2014 at 9:29 PM, Tony Arcieri basc...@gmail.com wrote:

 Anyone know why this hasn't gained adoption?

 http://tools.ietf.org/html/rfc2817

 I've been watching various efforts at widespread opportunistic encryption,
 like TCPINC and STARTTLS in SMTP. It's made me wonder why it isn't used for
 HTTP.

 Opportunistic encryption could be completely transparent. We don't need
 any external facing UI changes for users (although perhaps plaintext HTTP
 on port 80 could show a broken lock). Instead, if the server and client
 mutually support it, TLS with an unauthenticated key exchange is used.

 It seems most modern web browsers and web servers are built with TLS
 support. Why not always flip it on if it's available on both sides, even if
 it's trivially MitMed?

 --
 Tony Arcieri

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography





 ___
 The cryptography mailing list
 cryptogra...@metzdowd.com
 http://www.metzdowd.com/mailman/listinfo/cryptography

 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
 
 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] basing conclusions on facts (was: Re: Dual EC backdoor was patented by Certicom?)

[Stephen Farrell]

I've no public opinion on Certicom's patent practices. And the
behaviour of the signals intelligence agencies has been IMO
deplorable. So I sympathise with some of what you are saying.
However, building your case on bogus claims that are not facts
as you are pearly doing is a really bad idea. In particular...

On 15/06/14 14:13, ianG wrote:
 What is also curious is that Dan
 Brown is highly active in the IETF working groups for crypto, 

That is not correct as far as I can see. In my local archives,
I see one email from him to the TLS list in 2011 and none in
2012. For the security area list (saag), I see a smattering
of mails in 2011 and 2012 and none in 2013. For the IRTF's
CFRG, I see a few in 2010, none in 2011 and some in 2012 and
2013. I do see increased participation over the last year on
the the DUAL-EC topic.

None of the above is anywhere near highly active which is
therefore simply false.

And I don't believe you yourself are sufficiently active to
judge whether or not someone else is highly active in the
IETF to be honest. Nor do you seem to have gone through the
mail list archives to check.

You are both of course welcome to become highly active if you
do want to participate, same as anyone else.

 adding
 weight to the claim that the IETF security area is corrupted.

And that supposed conclusion, based only on an incorrect claim,
is utter nonsense. I would have expected better logic and closer
adherence to the facts.

Yes, the IETF security area needs to do better, and quite a few
folks are working on that. Yes, its almost certain the someone
was paid by BULLRUN to muck up IETF work. Nonetheless unfounded
misstatements such as the above don't help and are wrong. And
the correct reaction is to do better work and not to fall for
the same guily-by-association fallacy that the leads the spooks
to think that pervasive monitoring is a good plan.

S.

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] basing conclusions on facts

[Stephen Farrell]

On 15/06/14 19:16, ianG wrote:
 For my part, I had seen his name only with respect to IETF WGs.  However
 I admit that I do not follow IETF security WGs closely, so am not
 qualified to assert highly active.  You are right, I am wrong.

Thanks for that refreshing approach!

I appreciate it,
Cheers,
S.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL

[Stephen Farrell]

On 04/10/2014 12:29 AM, James A. Donald wrote:
 On 08/04/14 11:46, ianG wrote:
 We have here a rare case of a broad break in a security protocol leading
 to compromise of keys.
 
 On 2014-04-09 21:53, Alan Braggins wrote:
 Though it's an implementation break, not a protocol break.
 
 Not exactly.  The protocol failed to define a response to nonsensical
 records.  The bug was that the protocol responded to invalid records the
 same way as if they were valid.
 
 The protocol should have said  a valid record shall satisfy the
 following requirements.  Invalid records shall be silently discarded and
 all actions that depend on them silently terminated.

Well, the RFC [1] (end of p5) does say :

   If the payload_length of a received HeartbeatMessage is too large,
   the received HeartbeatMessage MUST be discarded silently.

I guess that doesn't say longer than actual payload though so
it doesn't explicitly call out the case that caused the problem.

I figure there are some protocol design lessons maybe. There's
a thread started on the TLS list about it today. [2] Be interesting
to see what that turns up.

S.

[1] https://tools.ietf.org/html/rfc6520
[2] https://www.ietf.org/mail-archive/web/tls/current/msg11891.html

 
 
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
 
 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] new IETF WG on Using TLS in Applications (uta) (was: Re: [Cryptography] Email is unsecurable)

[Stephen Farrell]

FYI, I said I'd send a mail back here when that new
working group was formed. That's happened now. [1]

Probably be a few days at least while folks sign up
to the list before stuff starts happening. If you're
interested in helping, sign up, write drafts, do all
the usual stuff. (If you don't know what that is,
or how to get involved, feel free to mail me and I
can try help.)

Cheers,
S.

[1] https://datatracker.ietf.org/wg/uta/charter/

On 11/25/2013 09:51 PM, Stephen Farrell wrote:
 
 
 On 11/25/2013 08:09 PM, Fabio Pietrosanti (naif) wrote:
 Let's first cut-off the massive passive traffic analysis, then improve
 current systems to provide some added protection against metadata,
 focusing in a far future, when the new system got already wide adoption,
 make it perfect.
 
 New work on improving hop-by-hop security for email and other
 things is getting underway in the IETF. [1] Basically the idea
 is to document stuff that can be turned on already in current
 deployments (to the extent possible) that gets you PFS and
 modern TLS ciphersuites. Pre-working-group charter discuss

I haven't had a chance to review the current draft in detail, but I
think the
language in the draft about this is fine.
ion for
 this is being directed to the apps-disc...@ietf.org list for
 now, or if folks aren't keen to get on that list, feel free to
 send me comments and I'll make sure they get into the pot. I'll
 send a mail here when the WG is officially kicked off (in a few
 weeks hopefully) with a pointer to the eventual wg mailing list.
 
 That does address the short-term/quick-win stuff that we can
 get for foo-over-TLS protocols like SMTP, IMAP etc., but doesn't
 address end-to-end mail security, for lots of the reasons already
 stated in this thread. So if you think there's value in that
 short-term work too, then I'm sure more help and expertise will
 be welcomed.
 
 Personally, I'm not at all confident that we can do something
 that provides end-to-end security, can be deployed at full
 Internet scale and is compatible with today's email protocols.
 But if others are more optimistic then I'm all for 'em trying
 to figure it out and would be delighted to be proven wrong.
 
 Cheers,
 S.
 
 
 [1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12140.html
 ___
 cryptography mailing list
 cryptography@randombit.net
 http://lists.randombit.net/mailman/listinfo/cryptography
 
 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Stephen Farrell]

Hiya,

On 11/27/2013 06:58 PM, Nico Williams wrote:
 I could imagine something like Received headers to document how each
 SMTP (and SUBMIT) end-point was authenticated (if they were) along a
 mail transfer path.  This would be of some utility, particularly for
 *short* paths (MUA-MSA-MTA-mailbox); for longer paths this loses its
 utility.

 Not sure I get the utility there, at least as in scope for
 this proposed WG. Do you mean the receiving MUA would display
 the message differently or something?
 
 Yes.  You get an e-mail from me.  Your edge MTA authenticated my MTA and
 my MTA claims to have authenticated me.  Add in a signature by my MSA
 over the relevant headers and body and your MUA can display my e-mail as
 more authenticated than one that transited a non-secure link (or where
 the transfer path was longer).

I'm not sure detecting the path length in terms of ADMDs is so
easy, not so useful in terms of MTAs (with all the spam checking
that can go on), nor that the above is really explicable to users.
We'd need to ask some mail folks.

But I like the emerging scheme below a good bit more:-)

 Note that there'd be a need for using DANE to authenticate MTAs acting
 as *clients*.  There'd be no need to prove the use of DANE for
 authenticating MTAs acting servers: if the mail gets to its intended
 destination, and the transit path is the shortest possible path, then
 we're good to go.  But it'd still be desirable to use DANE for
 authenticating MTAs acting servers: to prevent e-mail falling into the
 wrong hands.
 
 Note too that if a path is longer than the absolute shortest possible
 path then it's difficult to verify that there was no MITM in the path.
 That is, an MTA along the path could have had its DNS MX RR lookups
 spoofed so as to transfer my email to you via an MITM (who then gets to
 see it).  It's not like a client can prove to a server that the client
 used DANE to authenticate the server, so the servers can't protect
 against this.  The shortest path will generally be: my MUA-my MSA, my
 MTA - your MTA, your MTA - your mailbox.  Internal MTA hops on my
 and/or your side are irrelevant and can be noted as such or even not
 recorded (assuming our respective internal networks are secure).  Policy
 could be used to validate longer-than-shortest paths, but in practice
 just the shortest-path approach will suffice.
 
 There might be an idea there though if some of the hops used
 e.g. anon-DH and someone developed a generic witness protocol
 to help try spot MITM attacks on that, and if the MSA and MTAs
 DKIM-sign messages, then a message header field containing the
 inbound  outbound witness-protocol PDUs that was included in
 the DKIM signature could be good.
 
 If there's just anon-DH it's not terribly useful except as a way to
 bootstrap up to using DANE.  If you use DANE then you get the above
 property (all hops authenticated == much better than one [or more] hops
 not authenticated).

Not sure I agree with you there, esp if something could be
bound to DKIM at or by the ADMD TLS endpoints.

The problem with DANE is the lack of DNSSEC. If we had both
I fully agree it'd be better than using anon-DH. But I figure
there's a chance mail providers could do a DKIM thing in the
very near future and get some benefit.

Otherwise I think we're in agreement and I'll send a pointer
to this sub-thread to apps-discuss so follow up can happen
there. (I think you're on that list right?)

Cheers,
S.

 That sounds like it'd be a bit out the scope for UTA but if
 that's  what you meant (or similar) but I'd say a mail to
 apps-discuss on that would be useful.
 
 Right.
 
 But I don't think we'd want the UTA WG to be the one to
 develop a protocol for how to post-facto spot a MITM on anon-DH
 or other TLS sessions though. (Anyone got suggestions for that
 btw? Probably a different thread though.)
 
 Agreed.
 
 (And yes, the above would depend on DKIM public key records in
 the non-DNSSEC DNS, so a DANE like thing and DNSSEC would be
 stronger, but given that lots of large and small mail services
 already do DKIM and don't change their keys that often, even
 the non-DNSSEC thing might be good enough.)
 
 I'd prefer the hop-by-hop DANE thing for e-mail.  It makes much more
 sense.
 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Stephen Farrell]

On 11/27/2013 09:01 PM, Jeffrey Walton wrote:
 Isn't the key distribution problem being pushed into DNS? The
 underlying problem still exists.

Depends. If say someone ended up sampling the mail header
field values seen over a lot of messages then exceptions
to key continuity for mail service providers would perhaps
be enough to flag potential MITM attacks on the TLS
sessions, or odd MTAs popping up from nowhere, which are
at least some of the goals here.

So DKIM-level security could actually be quite useful in
this case I reckon.

S.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Stephen Farrell]

On 11/27/2013 09:29 PM, Nico Williams wrote:
 
 Viktor Dukhovni says that anything like DKIM/SPF is bound to fail.
 
 One problem is confusables: users can't really distinguish them, and
 some can be counted on just doing whatever it takes to give their money
 to the phisher, no matter what.  In other words, the problem with e-mail
 is that strangers can start conversations with you.  (Whereas with web
 services you start the conversations with them, which is not as big a
 problem.)

I'm not talking about MUAs at all here though.

On 11/27/2013 09:24 PM, Natanael wrote:
 So, Convergence/Perspectives done on email headers?


Almost. (I'm sure we could throw in a twist of CT too to
keep Ben happy:-)

But not with the goal of verifying web server public keys.
In this case we want to verify that the same TLS master
secret got used on each side of each TLS hop, even for
anon-DH. But I think is interesting to do that even at
the level where all we can detect a pervasive attack,
either due to different TLS master secrets where they
should be the same or else because of additional
unexpected or untraceable hops. (Maybe more is achievable
but that's the attack I'm thinking of right now.)

Mind you, even if it'd be ok crypto-wise, I'd not be
surprised if it falls down for some mail reason.

S.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] [Cryptography] Email is unsecurable

[Stephen Farrell]

On 11/25/2013 08:09 PM, Fabio Pietrosanti (naif) wrote:
 Let's first cut-off the massive passive traffic analysis, then improve
 current systems to provide some added protection against metadata,
 focusing in a far future, when the new system got already wide adoption,
 make it perfect.

New work on improving hop-by-hop security for email and other
things is getting underway in the IETF. [1] Basically the idea
is to document stuff that can be turned on already in current
deployments (to the extent possible) that gets you PFS and
modern TLS ciphersuites. Pre-working-group charter discussion for
this is being directed to the apps-disc...@ietf.org list for
now, or if folks aren't keen to get on that list, feel free to
send me comments and I'll make sure they get into the pot. I'll
send a mail here when the WG is officially kicked off (in a few
weeks hopefully) with a pointer to the eventual wg mailing list.

That does address the short-term/quick-win stuff that we can
get for foo-over-TLS protocols like SMTP, IMAP etc., but doesn't
address end-to-end mail security, for lots of the reasons already
stated in this thread. So if you think there's value in that
short-term work too, then I'm sure more help and expertise will
be welcomed.

Personally, I'm not at all confident that we can do something
that provides end-to-end security, can be deployed at full
Internet scale and is compatible with today's email protocols.
But if others are more optimistic then I'm all for 'em trying
to figure it out and would be delighted to be proven wrong.

Cheers,
S.


[1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12140.html
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] replacing passwords with keys is not so hard (Re: PBKDF2 + current GPU or ASIC farms = game over for passwords)

[Stephen Farrell]

On 10/01/2013 10:12 AM, Adam Back wrote:

 its impolite to point at your own designs 

Heh, I guess its ok to pile on so:-)

HOBA [1,2] is our similar idea. More focused on lower assurance
settings for now at least, on the basis that those passwords are
arguably more likely to leak and on being a straight drop-in
replacement a site can do all by themselves.

But the goal of getting rid of crappy passwords is the same and
is laudable mostly regardless of the scheme specifics.

S.

[1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba
[2] https://hoaba.ie/

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Q: CBC in SSH

[Stephen Farrell]

On 02/12/2013 12:04 AM, Peter Gutmann wrote:
 The problem with the cipher-suite explosion is that people want to throw in 
 vast numbers of pointless vanity suites and algorithms that no-one will ever 
 use

On balance I think the ciphersuite approach is slightly better
at being a slight counter to inevitable feature/cipher creep.
It does at least cause people to pause when they are about to
ask for another 96 ciphersuites as happened with certicom.

I also agree that only a very very few of the 320 or so TLS
ciphersuites are useful. The rest are just a PITA as far as I
can see. (Yes, 320. Sigh. [1])

S.

[1]
http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-3


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Q: CBC in SSH

[Stephen Farrell]

On 02/12/2013 12:42 AM, Nico Williams wrote:
 On Mon, Feb 11, 2013 at 6:23 PM, Stephen Farrell
 stephen.farr...@cs.tcd.ie wrote:
 On 02/12/2013 12:04 AM, Peter Gutmann wrote:
 The problem with the cipher-suite explosion is that people want to throw in
 vast numbers of pointless vanity suites and algorithms that no-one will ever
 use

 On balance I think the ciphersuite approach is slightly better
 at being a slight counter to inevitable feature/cipher creep.
 
 The ability to give an answer like we can't add your vanity cipher
 suite because of cartesian explosion seems like a weak justification
 for the cartesian explosion approach.

Yep. (Notice the 2 x slight above:-)

 
 If we want a policy of limiting what cipher suites we allocate
 codepoints to then we should have an *explicit* policy, and we should
 not wimp out when it comes time to enforcing it.
 
 But I don't think we have such a policy at the IETF.  

Right. And IETF policy is set by IETF participants. If you'd like
that to change, I'd say start on the saag list.

 The IETF policy
 regarding vanity cipher suites can be described as following some
 sturm und drang you'll get to have it, but only as OPTIONAL, described
 in an Informational RFC.
 
 Given the de facto policy at the IETF cartesian explosion is just
 silly -- so much foot self shooting.  Let's stop.
 
 It does at least cause people to pause when they are about to
 ask for another 96 ciphersuites as happened with certicom.

 I also agree that only a very very few of the 320 or so TLS
 ciphersuites are useful. The rest are just a PITA as far as I
 can see. (Yes, 320. Sigh. [1])
 
 So how well did cartesian explosion work as an implicit anti-vanity
 cipher suite policy work then?  Not very well, evidently!  :)

Well, we don't know that. It might have been worse.

 But I suspect that that was not the rationale way, way back when, back
 when cartesian explosion was selected.  The vanity cipher suite
 disincentive rationalization strikes me as a post-hoc one, and it
 doesn't work anyways.

Its not a rationalization. I said its slightly less bad not
that's why it was done. I wasn't involved in SSL when that
decision was made and have had little involvement in TLS at
all really.

But again, good ideas for helping improve things here would be
welcomed. (Oh, but its the IETF, so someone else will also hate
that same idea, but that's part of the beauty of going out and
meeting folk:-)

S.

 
 Please, let's go for an a-la-carte system.
 
 Nico
 --
 
 
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Fwd: Last Call: draft-laurie-pki-sunlight-05.txt (Certificate Transparency) to Experimental RFC

[Stephen Farrell]

There's been a bit of discussion about CT on this list
in the last few days.

If you've comments on CT then they'd be timely now, since
we're running an IETF last call on the draft (ends on Jan
24) with a view to pushing it out as an experimental track
RFC.

Cheers,
S.

PS: If you want to comment but aren't sure how, mail me
offlist.


 Original Message 
Subject: Last Call: draft-laurie-pki-sunlight-05.txt (Certificate
Transparency) to Experimental RFC
Date: Thu, 20 Dec 2012 11:33:58 -0800
From: The IESG iesg-secret...@ietf.org
Reply-To: i...@ietf.org
To: IETF-Announce ietf-annou...@ietf.org


The IESG has received a request from an individual submitter to consider
the following document:
- 'Certificate Transparency'
  draft-laurie-pki-sunlight-05.txt as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The aim of Certificate Transparency is to have every public end-
   entity (for example, web servers) and intermediate TLS certificate
   issued by a known Certificate Authority recorded in one or more
   certificate logs.  In order to detect misissuance of certificates,
   all logs are publicly auditable.  In particular, domain owners or
   their agents will be able to monitor logs for certificates issued on
   their own domain.

   To protect clients from unlogged misissued certificates, each log
   signs all certificates it records, and clients can choose not to
   trust certificates that are not accompanied by an appropriate log
   signature.  For privacy and performance reasons log signatures are
   embedded in the TLS handshake via the TLS authorization extension, in
   a stapled OCSP extension, or in the certificate itself via an X.509v3
   certificate extension.

   To ensure a globally consistent view of any particular log, each log
   also provides a global signature over the entire log.  Any
   inconsistency of logs can be detected through cross-checks on the
   global signature.  Consistency between any pair of global signatures,
   corresponding to snapshots of a particular log at different times,
   can be efficiently shown.

   Logs are only expected to certify that they have seen a certificate,
   and thus we do not specify any revocation mechanism for log
   signatures in this document.  Logs are append-only, and log
   signatures do not expire.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ballot/




___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography